Esto es realmente ambivalente. Por un lado, está buenísimo. Me pregunto si habrá alguien que no haya pasado por una reunión de limpieza del backlog donde se va raspando desde arriba, aun sabiendo que nunca se llegará al final, y esa sensación es definitivamente miserable.
Por otro lado, los issues no desaparecieron, solo cambiaron de etiqueta, y si todo es un problema de etiquetas y organización, ¿no sería mejor dejarlo fluir en vez de intentar controlar esa especie de utopía falsa de una lista de issues perfectamente vacía? Seguro también hay beneficios en dejar esas notas en un lugar visible. Es parecido a cuando, en medio de una gran limpieza, decidís tirar algo, pero el inconsciente te dice que lo conserves porque tal vez lo necesites después.
Aun así, en general estoy a favor. Como mínimo, creo que dará una sensación de liberación y un efecto de recarga para los nuevos issues.
Para agregar un poco más de contexto, el creador está haciendo una reescritura completa.
Creo que habría sido más prolijo lanzar primero la versión reescrita y después cerrar los issues existentes como deprecated. Los issues de la rama de reescritura podrían haberse separado con etiquetas de versión. Si se cierran mientras la nueva versión todavía no está terminada, los contribuidores podrían abrir nuevos issues para la versión existente sin saber que ya no recibe soporte.
Aun así, no es que se estén ignorando los issues y dejando problemas en la base de código; el proyecto entero está siendo reacondicionado. https://twitter.com/jdalton/status/1571863497969119238
Desde el punto de vista del usuario, si esta “limpieza” significa cerrar issues, hay un problema. Si el issue todavía existe en el producto, debería permanecer abierto tanto por documentación como para que otros usuarios que tengan el mismo problema puedan encontrarlo fácilmente y sumarse.
Creo que es más honesto que el proyecto reconozca la existencia de los issues y los deje abiertos. Desde el punto de vista de los desarrolladores, si les molesta la cantidad de issues, sería mejor usar un filtro que oculte los issues viejos y poco importantes.
Yo también tengo sentimientos encontrados. Por un lado, cada vez que vuelvo a trabajar con JavaScript termino buscando lodash. Por otro lado, creo que un poco menos de la mitad de esta biblioteca debería, por favor, estar en la biblioteca estándar.
¿No se supone que este es el tipo de tarea en la que los modelos de lenguaje grandes deberían ser buenos? Me refiero a resumir tickets.
Por eso Basecamp no mantiene un backlog. Lo importante vuelve a aparecer.
jwz dijo esto:
Creo que esta es la forma más común en que se cierran los bugs que reporté en proyectos de software open source. Reportás un bug y queda sin leerse durante un año, a veces dos, hasta que un día ese módulo se reescribe desde cero. Y el nuevo mantenedor no tiene ganas de comprobar si la nueva versión realmente resolvió los problemas conocidos que existían en la versión anterior.
Si se trata de un proyecto con pocos mantenedores o de una sola persona, ¿no sería más razonable que los reportantes de bugs dedicaran 10 o 15 minutos cada uno a verificar si el problema todavía existe, en vez de que el mantenedor único pase de varios días a semanas validándolo?
Especialmente si es un bug difícil o complejo de reproducir: para empezar, ni siquiera es seguro que el mantenedor pueda reproducirlo en su propio entorno, y es muy probable que quien lo reportó esté más acostumbrado a observar ese bug.
Si hay un equipo más grande o si es un proyecto asociado a un servicio comercial, ese equilibrio puede cambiar un poco.
Lo que se ve en muchos proyectos libres/open source es que hay muy poca gente dispuesta a arremangarse, pero a la vez se dedica bastante tiempo a informar lo esencial que es ese proyecto para uno, a exigir cosas y a hacer muchas sugerencias.
La mayoría crea issues nuevos para comunicar una lista de deseos o deja reportes de bugs muy vagos. Algunos de ellos entregan buenos reportes de bugs, pero la voluntad de contribuir suele llegar solo hasta ahí.
Personalmente, no tengo la disposición para manejar diplomáticamente la mayoría de los comentarios habituales, así que no tengo el carácter para mantener proyectos.
Aun así, con los issues que reporto siempre intento hacer mi parte: rastrear la causa y, si es posible, enviar un PR que lo corrija.
También existe una variante: se reporta un issue para una versión mayor, sale una nueva versión mayor y, aunque no sea una reescritura sino solo cambios graduales, se cierran todos los issues de releases anteriores porque el problema podría ya no existir.
Se puede crear un PR con pruebas que deberían pasar, pero que actualmente estén marcadas para omitirse. Así, al reconstruir, queda un camino fácil para revisar el avance y ver si hubo mejoras.
Si de verdad te importa un problema, hay que agregarle tests.
A veces los hallazgos de seguridad también se tratan así.
Mi experiencia es la misma incluso en proyectos de software de código cerrado.
John-David Dalton, autor de lodash, [escribió esto el año pasado][1]:
En la reescritura de lodash voy a declararme en bancarrota por deuda técnica. Empiezo desde cero con TypeScript y Rollup. No habrá wrapper FP. Esa moda ya terminó. Mis condolencias para los compañeros de quien haya metido ese dolor de cabeza en la base de código. No es amigable ni para equipos ni para personas.
No sé si se cumplirá al 100%, pero parece bastante cercano.
[1]: https://twitter.com/jdalton/status/1571863497969119238
“Esa moda ya terminó. Mis condolencias para los compañeros de quien haya metido ese dolor de cabeza en la base de código. No es amigable ni para equipos ni para personas.” ¿Pero el autor original no fue él mismo?
Suena como si otra persona hubiera agregado la complejidad que está criticando. Si lo introdujo él, en vez de hablarlo como retrospectiva o aprendizaje, parece decir que desarrolló el proyecto siguiendo una moda y que, como esa moda ya terminó, ahora es momento de pasar a la siguiente.
¿Qué era el wrapper FP y qué moda era esa?
No conozco bien los issues del lado de JavaScript, pero en este contexto, ¿cuál es el problema con la programación funcional?
Bien hecho.
Con solo ver algunos PR al principio de la lista, hay cosas como estas:
agregar una palabra en un comentario, agregar un archivo de configuración para promocionar un servicio de desarrollo, cambiar var por let, modificar el comportamiento bien establecido de una función central, eliminar punto y coma, etc.
La mayoría probablemente se abrió con la buena intención de mejorar la biblioteca, pero en algún momento para el mantenedor eso simplemente se convierte en spam o, peor aún, en una carga que aumenta la culpa cuanto menos puede prestarle atención.
Así como las celebridades contratan guardaespaldas y viajan en primera clase o en jets privados para evitar la atención constante y proteger su salud mental, me pregunto qué tipo de medidas podrían aplicarse a proyectos open source famosos.
Personalmente, como mantenedor open source, los PR de corrección de typos, ajustes de redacción y refactorizaciones automáticas son los que más me gustan. Casi no requieren esfuerzo de revisión, así que casi siempre los fusiono muy rápido.
Lo que más tiempo lleva son los PR que implementan funcionalidades enormes. Requieren mucha revisión y discusión, así que termino postergando mirarlos en detalle.
Durante un tiempo estuvo de moda abrir PR triviales en proyectos famosos. Creo que era un intento de rellenar el currículum.
Hubo un usuario específico de GitHub que enviaba repetidamente a varios proyectos JavaScript PR que solo cambiaban var por let.
Se sentía como si estuviera rellenando su perfil de GitHub.
Wow.
Ya me estaba empezando a interesar mover mis paquetes a Bun, pero venía dudando por la compatibilidad y por si Bun realmente iba a sobrevivir. También quedé algo escaldado con “Modern Yarn”. Pero ver que lodash se pasa me dan ganas de evaluarlo más en serio.
Sí, esto es una noticia importante. Sobre todo considerando que, pese al reciente lanzamiento de v1.0, todavía hay problemas de rendimiento en Windows.
Trato de evitar decirles a los desarrolladores open source cómo deberían gestionar sus proyectos. Yo también soy desarrollador open source, y me molesta cuando otros me hacen eso.
Pero si yo hubiera sido un usuario que dedicó bastante tiempo a escribir issues y ayudar a resolver problemas, o alguien que trabajó en una corrección o una nueva funcionalidad y envió un PR, creo que ahora estaría bastante desmotivado.
Pero la mayoría de los usuarios solo dedica un tiempo mínimo a escribir issues. La mayoría de los reportes de bugs son pésimos.
Los issues se cerraron, no desaparecieron. Si siguen siendo relevantes, supongo que se pueden volver a solicitar más adelante.
La bancarrota de issues es real. Hablando por experiencia personal, en cierto punto mantener open source se vuelve difícil de compatibilizar con vivir en el mundo real.
El trabajo es gratis y a menudo no se agradece. Claro, no siempre es así. Los problemas son complejos y compiten con responsabilidades reales como el trabajo, la familia y el descanso. La gente se irrita fácilmente y regularmente quiere discutir o que le lean la documentación por ella. Cuando el open source es famoso, también viene con una responsabilidad enorme.
Creo que habrá un gran colapso en el ecosistema open source cuando las personas que lideran proyectos digan “ya fue” y se vayan a hacer cosas más importantes.
Lo entiendo. Últimamente incluso he llegado a pensar que los proyectos personales no triviales se parecen más a una adicción o autolesión que a proyectos reales.
Dicho eso, el ecosistema open source es absurdamente ineficiente. Están lodash, underscore y muchísimas otras bibliotecas, y no todas necesitan existir. También hay muchas bibliotecas que hacen una sola cosa y, por lo general, son subconjuntos de estas.
La mayoría de estas cosas se usan junto con minificadores y tree shaking, y se eliminan las funciones no utilizadas. Incluso las bibliotecas pesadas se optimizan fácilmente y suelen estar compuestas por partes separadas, así que no hace falta necesariamente una biblioteca liviana, y el esfuerzo de desarrollo en general crece de forma lineal.
Si no fuera porque a los programadores les encantan la elegancia y la simplicidad por encima de todo, y porque siempre quieren reescribir las cosas para hacerlas apenas mejores, creo que al open source le alcanzaría con personal de sobra incluso si todos dedicaran solo una cuarta parte del tiempo que dedican ahora.
Lodash es una excelente biblioteca. Termino usándola un poco en casi todos los proyectos en los que trabajo.
Pero a medida que JavaScript mejora cada vez más, uso Lodash cada vez menos. Cada vez que la uso, reviso si existe una funcionalidad nativa para lo que quiero hacer. También me pasa bastante seguido comentar en PR con enlaces diciendo “para esto no hace falta Lodash”.
Aun así, espero que esto no sea una señal de que se estén alejando del proyecto.
Definitivamente es cómoda, pero al final, si necesito utilidades, creo que preferiría versiones hechas por mí.
No uso lodash ni underscore.js desde hace 8 años. No tengo muy claro qué cosas no se pueden hacer fácilmente con map, filter, find, etc.
En un tracker de issues se superponen dos usos. Uno es como forma de dar seguimiento a las tareas que deben hacer los mantenedores, y el otro es como forma de que la comunidad más amplia y los usuarios den seguimiento a los defectos del software.
Declararse en “bancarrota de issues” tiene sentido para el primer uso, pero en el segundo implica borrar información valiosa sobre issues que existen en la versión actual.
1 comentarios
Opiniones de Hacker News
Esto es realmente ambivalente. Por un lado, está buenísimo. Me pregunto si habrá alguien que no haya pasado por una reunión de limpieza del backlog donde se va raspando desde arriba, aun sabiendo que nunca se llegará al final, y esa sensación es definitivamente miserable.
Por otro lado, los issues no desaparecieron, solo cambiaron de etiqueta, y si todo es un problema de etiquetas y organización, ¿no sería mejor dejarlo fluir en vez de intentar controlar esa especie de utopía falsa de una lista de issues perfectamente vacía? Seguro también hay beneficios en dejar esas notas en un lugar visible. Es parecido a cuando, en medio de una gran limpieza, decidís tirar algo, pero el inconsciente te dice que lo conserves porque tal vez lo necesites después.
Aun así, en general estoy a favor. Como mínimo, creo que dará una sensación de liberación y un efecto de recarga para los nuevos issues.
Creo que habría sido más prolijo lanzar primero la versión reescrita y después cerrar los issues existentes como deprecated. Los issues de la rama de reescritura podrían haberse separado con etiquetas de versión. Si se cierran mientras la nueva versión todavía no está terminada, los contribuidores podrían abrir nuevos issues para la versión existente sin saber que ya no recibe soporte.
Aun así, no es que se estén ignorando los issues y dejando problemas en la base de código; el proyecto entero está siendo reacondicionado.
https://twitter.com/jdalton/status/1571863497969119238
Creo que es más honesto que el proyecto reconozca la existencia de los issues y los deje abiertos. Desde el punto de vista de los desarrolladores, si les molesta la cantidad de issues, sería mejor usar un filtro que oculte los issues viejos y poco importantes.
jwz dijo esto:
Especialmente si es un bug difícil o complejo de reproducir: para empezar, ni siquiera es seguro que el mantenedor pueda reproducirlo en su propio entorno, y es muy probable que quien lo reportó esté más acostumbrado a observar ese bug.
Si hay un equipo más grande o si es un proyecto asociado a un servicio comercial, ese equilibrio puede cambiar un poco.
Lo que se ve en muchos proyectos libres/open source es que hay muy poca gente dispuesta a arremangarse, pero a la vez se dedica bastante tiempo a informar lo esencial que es ese proyecto para uno, a exigir cosas y a hacer muchas sugerencias.
La mayoría crea issues nuevos para comunicar una lista de deseos o deja reportes de bugs muy vagos. Algunos de ellos entregan buenos reportes de bugs, pero la voluntad de contribuir suele llegar solo hasta ahí.
Personalmente, no tengo la disposición para manejar diplomáticamente la mayoría de los comentarios habituales, así que no tengo el carácter para mantener proyectos.
Aun así, con los issues que reporto siempre intento hacer mi parte: rastrear la causa y, si es posible, enviar un PR que lo corrija.
Si de verdad te importa un problema, hay que agregarle tests.
John-David Dalton, autor de lodash, [escribió esto el año pasado][1]:
Suena como si otra persona hubiera agregado la complejidad que está criticando. Si lo introdujo él, en vez de hablarlo como retrospectiva o aprendizaje, parece decir que desarrolló el proyecto siguiendo una moda y que, como esa moda ya terminó, ahora es momento de pasar a la siguiente.
Bien hecho.
Con solo ver algunos PR al principio de la lista, hay cosas como estas:
agregar una palabra en un comentario, agregar un archivo de configuración para promocionar un servicio de desarrollo, cambiar
varporlet, modificar el comportamiento bien establecido de una función central, eliminar punto y coma, etc.La mayoría probablemente se abrió con la buena intención de mejorar la biblioteca, pero en algún momento para el mantenedor eso simplemente se convierte en spam o, peor aún, en una carga que aumenta la culpa cuanto menos puede prestarle atención.
Así como las celebridades contratan guardaespaldas y viajan en primera clase o en jets privados para evitar la atención constante y proteger su salud mental, me pregunto qué tipo de medidas podrían aplicarse a proyectos open source famosos.
Lo que más tiempo lleva son los PR que implementan funcionalidades enormes. Requieren mucha revisión y discusión, así que termino postergando mirarlos en detalle.
varporlet.Se sentía como si estuviera rellenando su perfil de GitHub.
La noticia más grande es que Lodash se está moviendo de Node.js a Bun: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
Ya me estaba empezando a interesar mover mis paquetes a Bun, pero venía dudando por la compatibilidad y por si Bun realmente iba a sobrevivir. También quedé algo escaldado con “Modern Yarn”. Pero ver que lodash se pasa me dan ganas de evaluarlo más en serio.
Trato de evitar decirles a los desarrolladores open source cómo deberían gestionar sus proyectos. Yo también soy desarrollador open source, y me molesta cuando otros me hacen eso.
Pero si yo hubiera sido un usuario que dedicó bastante tiempo a escribir issues y ayudar a resolver problemas, o alguien que trabajó en una corrección o una nueva funcionalidad y envió un PR, creo que ahora estaría bastante desmotivado.
Etiquetaron 363 issues con
issue bankruptcyy los cerraron: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...Los PR también, 325 de la misma forma: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
La bancarrota de issues es real. Hablando por experiencia personal, en cierto punto mantener open source se vuelve difícil de compatibilizar con vivir en el mundo real.
El trabajo es gratis y a menudo no se agradece. Claro, no siempre es así. Los problemas son complejos y compiten con responsabilidades reales como el trabajo, la familia y el descanso. La gente se irrita fácilmente y regularmente quiere discutir o que le lean la documentación por ella. Cuando el open source es famoso, también viene con una responsabilidad enorme.
Creo que habrá un gran colapso en el ecosistema open source cuando las personas que lideran proyectos digan “ya fue” y se vayan a hacer cosas más importantes.
Dicho eso, el ecosistema open source es absurdamente ineficiente. Están lodash, underscore y muchísimas otras bibliotecas, y no todas necesitan existir. También hay muchas bibliotecas que hacen una sola cosa y, por lo general, son subconjuntos de estas.
La mayoría de estas cosas se usan junto con minificadores y tree shaking, y se eliminan las funciones no utilizadas. Incluso las bibliotecas pesadas se optimizan fácilmente y suelen estar compuestas por partes separadas, así que no hace falta necesariamente una biblioteca liviana, y el esfuerzo de desarrollo en general crece de forma lineal.
Si no fuera porque a los programadores les encantan la elegancia y la simplicidad por encima de todo, y porque siempre quieren reescribir las cosas para hacerlas apenas mejores, creo que al open source le alcanzaría con personal de sobra incluso si todos dedicaran solo una cuarta parte del tiempo que dedican ahora.
Lodash es una excelente biblioteca. Termino usándola un poco en casi todos los proyectos en los que trabajo.
Pero a medida que JavaScript mejora cada vez más, uso Lodash cada vez menos. Cada vez que la uso, reviso si existe una funcionalidad nativa para lo que quiero hacer. También me pasa bastante seguido comentar en PR con enlaces diciendo “para esto no hace falta Lodash”.
Aun así, espero que esto no sea una señal de que se estén alejando del proyecto.
..., tuvo un impacto enorme. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Los helpers de iteradores también se van a publicar pronto, y serán de gran ayuda. Los helpers de iteradores asíncronos probablemente se retrasen un buen tiempo. https://github.com/tc39/proposal-iterator-helpersAntes sentía que tenía que usar
.apply()varias veces por semana para llamar funciones de formas creativas en el código base donde trabajaba. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Ahora todo eso desapareció, y creo que estaría bastante dividido si el 50% del equipo conoce.cally.applyo no.Chrome 117 incorpora
Object.groupBy(), y eso ayudará mucho a eliminar muchos de los últimos casos por los que uno termina usando lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,find, etc.En un tracker de issues se superponen dos usos. Uno es como forma de dar seguimiento a las tareas que deben hacer los mantenedores, y el otro es como forma de que la comunidad más amplia y los usuarios den seguimiento a los defectos del software.
Declararse en “bancarrota de issues” tiene sentido para el primer uso, pero en el segundo implica borrar información valiosa sobre issues que existen en la versión actual.