Ama a tus Mantenedores

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

Ahora, el secreto está en la locura, es cómo le pides a la gente que haga cosas. Permítanme demostrárselo. En primer lugar, me gustaría presentarme. Soy Paolo, soy miembro de Node.tsc y también ingeniero principal en Platformatic. Pueden encontrar todos mis contactos allí abajo, especialmente mi sitio web, que acabo de rediseñar, así que les animo a echar un vistazo y darme su opinión, por favor.

Bien, ahora sigamos adelante. ¿Qué esperan, pretenden, del código abierto? ¿Cuál es el verbo correcto a usar? En primer lugar, aclaremos qué es realmente 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 70 en el movimiento de software libre que desafió al desarrollo tradicional basado en el lucro como de costumbre. El problema es que en inglés, como pueden imaginar, free significa demasiado, gratis. Significa gratis como en no pagado, y gratis como en libertad es ambiguo. No pagado era obviamente el significado más entendido de la palabra. Por lo tanto, se cambió a código abierto, que es una rama del movimiento de software libre. Así que obtenemos 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, dar libertad. La libertad se mantiene.

Ahora, ¿por qué alguien querría adoptar el código abierto? Ahora, ¿por qué alguien querría adoptar el código abierto? Porque, y permítanme citar aquí, puedes obtener lo mejor de lo mejor de lo mejor. Puedes acceder a una base de desarrolladores que ni siquiera está remotamente, físicamente cerca de ti, y puedes acceder a diferentes antecedentes culturales 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 se asemeja a algo, ¿verdad? ¿Les suena familiar? Bueno, el código abierto es similar al trabajo remoto, pero no lo es. Tengan 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 impulsadas por la pasión, no por el dinero. Y además, tú no eres su jefe. Recuerda eso. No eres su jefe. No puedes exigir nada. Puedes pedir, pero no puedes exigir. No puedes dar órdenes. No puedes dar instrucciones. Pero, en general, todos son amables si las personas son amables.

Ahora, recuerda, las personas en el código abierto están impulsadas por la pasión. Los mantenedores simplemente aman que uses su software. De lo contrario, nunca tendrían código abierto para mantener. 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 pasión. No les estás pagando a menos que los patrocines. Pero eso es un tema diferente.

Recuerda que las acciones tienen consecuencias, como siempre. Si finges arreglos, si finges 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 solo es 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, al igual que tú, tienen sentimientos, tienen necesidades y tienen trabajo en tiempo real. Tienen una vida real. Tienen hobbies. Tienen familia. Tienen hijos a los que cuidar, y así sucesivamente.

Como puedes ver en la captura de pantalla, tomé una captura de la página de GitHub del proyecto LWJS, que fue gestionado por James Sumner, quien recibió un mensaje desagradable, desagradable, desagradable y sinceramente completamente sin sentido de una persona que fue capaz de poner una gran cantidad de palabras malsonantes, ofensas y groserías en solo seis líneas de texto. Por lo tanto, James se agotó y dijo, ¿sabes qué? Ya no quiero hacerlo. 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. Todavía puedes bifurcarlo, obviamente, porque James era una buena persona. Podría haber eliminado este proyecto por completo, pero era una buena persona. Optó por decir simplemente que el proyecto ahora está archivado. Si quieres bifurcarlo, ahora es tuyo. Ya no voy a dedicarle mi tiempo. Entonces, esa grosería inútil no llegó a ninguna parte, ¿verdad? Por favor, evítalo. Sé amable con las personas. Sé muy amable con las personas. El aspecto humano es lo que más me importa hoy. 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, digamos que somos amables. Somos personas que eventualmente podemos comportarnos de la manera correcta. ¿Cómo pides 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 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 cuando tengo que hacer una búsqueda.

En primer lugar, comienzo con los problemas. Veamos si tengo un problema que alguien ya haya encontrado. Cuanto más fácil sea reproducir este problema, mayor será la probabilidad de que alguien ya lo haya reportado, 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 (PRs). Tal vez alguien haya notado que en lugar de presentar directamente un problema, propuso una solución para él, así que las PRs son las siguientes. Luego, está el code. Intenta investigar en la base de code, si es posible, y busca si ya hay alguna pista sobre cómo solucionar tu problema. Tal vez simplemente estés utilizando el software de manera incorrecta. La documentación actualizada es lo último. Tal vez haya una página muy ingeniosa en la documentación que tenga una solución alternativa para el problema, o que especifique que este problema no será cubierto, porque podría serlo. Por supuesto, esta lista es después de que ya hayas leído la documentación sobre cómo utilizar el software, porque asumo que ya lo hiciste. En otras palabras, por favor, no esperes que alguien te responda sin haber leído el maldito manual, ¿de acuerdo? ¿Está claro? 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 de reproducir, y nadie lo ha reportado nunca, y nadie ha presentado una PR para eso, amigo, lo estás utilizando de manera incorrecta. O estás muerto. Te lo digo porque me ha pasado muchas veces. No pude encontrar ninguna solución. No pude explicar por qué nadie ha encontrado nunca 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 de todos modos. Otra cosa muy importante. Vivimos en un mundo distribuido. Vivimos en un mundo donde estamos distribuidos por todo el globo, donde las personas provienen de diferentes culturas, con diferentes expectativas, conocimientos y experiencia.

No estoy hablando solo de dos personas. Estoy hablando en general. Así que nunca te preocupes por comunicarte demasiado. Proporciona tantos detalles como desees. Volveré sobre esto más adelante.

Y no temas molestar a las personas con una comunicación excesiva. Cuantos más detalles importantes puedas proporcionar, mejor. Piensa en esto. Los mantenedores tienen su propia vida. Es posible que no tengan tiempo para solicitar información adicional, y por lo tanto no procesarán tu informe si les falta información crucial. Así que no temas comunicarte demasiado. Y olvídate. Y esto te sorprenderá.

Trabajar en código abierto y reportar problemas e investigar problemas es como ser periodista. ¿Recuerdas las reglas de WH? Entonces, 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 intenta ser explícito si puedes. Por supuesto, no proporciones información inútil, pero puedes hacerlo.

Luego, y esto es lo más importante, qué y cuándo. Explica qué sucedió, qué no sucedió, y qué esperamos que haga el software en realidad. Y cuándo sucede, qué estamos haciendo cuando eso sucede. Intenta proporcionar el contexto más completo posible. Luego está el cómo. Y recuerda, esto volverá. ¿Cuál es la forma más pequeña de reproducir el problema? No nos importa, quiero decir, tienes una aplicación increíble. Puede que 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. No nos importa. Intenta 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 las cinco W, ¿verdad? No lo he olvidado. El 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 un PR. 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 code 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 pensando en hablar sobre la comunicación excesiva. Pero asegúrate de no abrumar a los mantenedores con información inútil. No tienes que preocuparte por comunicarte demasiado, pero tampoco puedes excederte, por supuesto. Como dicen en latín, in medio stat virtus. Así que la virtud está en el medio. No puedes enviar toneladas de salida o tal vez gigabytes de salida en un problema porque nadie lo va a leer. Además, los informes con mucha información probablemente distraerán a los mantenedores, lo que en algún momento hará que pierdan interés y ni siquiera miren el problema, incluso si están dispuestos a ayudar. Además, lo cual es la 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. Intenta 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 una solución o algo así, es crear lo que llamaré repositorios reproducibles. Entonces, si obtienes un software y lo estás usando, puedes crear un repositorio solo para ese problema que contenga solo los detalles mínimos necesarios para reproducir el problema. Por supuesto, debes eliminar toda la información sensible o enmascararla y proporcionar un repositorio público. Así los triagers o mantenedores pueden clonar tu repositorio, iniciar el repositorio, examinar el problema, aislarlo y solucionarlo. Esa es, con mucho, la mejor manera de obtener una solución. No te voy a decir cómo crear esto, puedes buscarlo en línea, pero lo esencial es que sea mínimo, aislado, público y sin información sensible.

Si sigues eso, estás bien. Sigamos adelante.

El último advice que quiero darte es el seguimiento. Es muy molesto si presentas un problema y luego te olvidas de él y luego regresas después de un mes y dices, oh amigo, ¿se solucionó eso? Probablemente no. Si el mantenedor te pide más información de inmediato, y tú nunca respondes, el mantenedor queda atascado. No tenemos una bola mágica, no podemos predecir el futuro, así que debes proporcionar toda la información que te pedimos para solucionar el problema. Además, esta es tu única oportunidad de ser escuchado. Si el problema implica básicamente una característica que falta o una mejora que se puede hacer, y si quieres participar y dar tu opinión, este es el último momento. Una vez que se soluciona el problema, se fusiona la nueva característica, se realiza el nuevo PR, ya no tienes voz. Sin embargo, 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á involucrado el problema de semantic versioning y demás.

Entonces mi advice es configurar 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 tanto de las tendencias y seguir la discussion. El último paso, que es trivial ya que es de código abierto, pero es probablemente mejor decirlo, eres más que bienvenido a participar. Si tienes experiencia y entiendes lo que está sucediendo, proporciona la 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 para code, también, una forma en la que puedes contribuir es probar la nueva característica y el problema que el mantenedor solucionó para ti de inmediato. Así puedes apoyar realmente al mantenedor diciendo que el problema ya no existe. He solucionado el problema, podemos seguir adelante con nuestras vidas. Además, proporciona retroalimentación de inmediato. Simplemente estar en silencio y decir, está bien, he terminado. No es suficiente. Tal vez solo un comentario simple en el problema. Di, gracias, amigo, lo solucionaste en la versión 1.2.3. Es absolutamente suficiente. Pero al menos hágales saber que todo está bien, y luego pasa al siguiente problema. Y un último paso, no olvides agradecerles. Muy bien, amigos.

Una vez más, nosotros somos, y tú eres, si también eres un mantenedor, o si serás un mantenedor, seguimos siendo personas. Dependemos de la amabilidad. Ok, no olvides agradecer a las personas por el tiempo que te han dado. No es que el mantenedor te agradezca por el problema que has reportado, y tú les agradezcas por el problema que han solucionado. Funciona así. Como usualmente agradeces a las personas cuando te pasan la sal, o cualquier cosa así cuando estás almorzando. Ok, no lo olvides. Eso es muy importante.

Entonces, esa fue una breve descripción de cómo puedes apoyar a tus mantenedores. Permíteme resumirlo para ti. La amabilidad primero, siempre. Ellos no te deben nada, y siempre es bueno ser amable cuando les estás pidiendo ayuda. Apóyalos, mantente disponible, eventualmente contribuye si puedes, involúcrate y, una vez más, buenos modales y amabilidad, y agradéceles. Una vez más, la amabilidad es la palabra clave.

Y es por eso que, como suelo hacer en mis charlas, me gusta terminar mis charlas con una famosa cita 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. Ok, 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.