Isto é realmente ambivalente. Por um lado, é ótimo. Quem nunca passou por uma reunião de limpeza de backlog em que se vai raspando de cima para baixo, mesmo sabendo que nunca se vai chegar ao fim? A sensação é certamente miserável.
Por outro lado, as issues não desapareceram, só ganharam outro rótulo; e, se tudo é uma questão de tags e organização, talvez seja melhor deixar o fluxo seguir em vez de tentar controlar essa quase utopia de uma lista de issues perfeitamente vazia. Também deve haver vantagens claras em deixar essas anotações em um lugar visível. É parecido com aquela sensação, durante uma grande faxina, de decidir jogar algo fora, mas o inconsciente insistir que talvez seja necessário mais tarde.
Ainda assim, no geral sou a favor. No mínimo, deve trazer uma sensação de libertação e um efeito de recarga para novas issues.
Para acrescentar um pouco mais de contexto, o criador está fazendo uma reescrita completa.
Acho que teria sido mais limpo lançar primeiro a versão reescrita e depois fechar as issues antigas como deprecated. As issues do branch de reescrita poderiam ter sido separadas por tags de versão. Se elas forem fechadas antes de a nova versão estar pronta, colaboradores podem abrir novas issues na versão antiga sem saber que ela não recebe mais suporte.
Ainda assim, não é que ele esteja ignorando as issues e deixando problemas no codebase; o projeto inteiro está sendo renovado. https://twitter.com/jdalton/status/1571863497969119238
Do ponto de vista do usuário, se esse tipo de “organização” significa fechar issues, há um problema. Se é uma issue que ainda existe no produto, ela deveria continuar aberta tanto por documentação quanto para que usuários que enfrentem o mesmo problema possam encontrá-la facilmente e acrescentar informações.
Acho mais honesto o projeto reconhecer a existência das issues e mantê-las abertas. Do ponto de vista dos desenvolvedores, se a quantidade de issues incomoda, seria melhor usar filtros para ocultar issues antigas e sem importância.
Também fico dividido. Por um lado, toda vez que volto a trabalhar com JavaScript acabo procurando o lodash. Por outro, acho que um pouco menos da metade desta biblioteca deveria, por favor, estar na biblioteca padrão.
Esse não é o tipo de tarefa em que modelos de linguagem grandes deveriam ser bons? Quero dizer, resumo de tickets.
É por isso que a Basecamp não mantém backlog. O que é importante volta a aparecer.
jwz disse isto:
Acho que esta é a forma mais comum pela qual bugs que reportei em projetos de software open source são fechados. Você reporta um bug, ele fica sem ser lido por um ano, às vezes dois, e então um dia aquele módulo é reescrito do zero. E o novo mantenedor não tem disposição para verificar se a nova versão de fato resolveu o problema conhecido que existia na versão anterior.
Em projetos com poucos mantenedores ou de uma só pessoa, não seria mais razoável que os autores dos relatos de bug gastassem 10 a 15 minutos cada um para verificar se o problema ainda existe, em vez de o mantenedor único passar dias ou semanas fazendo essa validação?
Especialmente se for um bug difícil ou complexo de reproduzir, nem é certo que o mantenedor consiga reproduzi-lo no próprio ambiente, e é bem provável que quem reportou esteja mais acostumado a observar esse bug.
Se houver uma equipe maior, ou se for um projeto associado a um serviço comercial, esse equilíbrio pode mudar um pouco.
O que se vê em muitos projetos livres/open source é que pouquíssimas pessoas querem arregaçar as mangas, mas ao mesmo tempo gastam bastante tempo informando o quanto o projeto é essencial para elas, fazendo exigências e dando muitas sugestões.
A maioria cria novas issues para comunicar listas de desejos ou deixa relatos de bug muito vagos. Alguns até entregam bons relatórios de bug, mas em geral a disposição para contribuir para por aí.
Pessoalmente, não tenho disposição para lidar diplomaticamente com a maioria dos comentários que aparecem com frequência, então não tenho o perfil para manter projetos.
Ainda assim, nas issues que eu reporto, sempre tento fazer minha parte: investigar a causa e, quando possível, enviar um PR corrigindo.
Também há uma variação disso. Uma issue é reportada para uma versão major; aí sai uma nova versão major e, mesmo sem reescrita, apenas com mudanças incrementais, todas as issues de releases anteriores são fechadas sob o argumento de que o problema pode não existir mais.
Basta criar um PR com testes que deveriam passar, mas que no momento estejam marcados para serem pulados. Assim, ao reconstruir, existe um caminho fácil para verificar o andamento e ver se houve melhora.
Se é um problema com o qual você realmente se importa, é preciso adicionar testes.
Descobertas de segurança às vezes também são tratadas assim.
Minha experiência é a mesma em projetos de software de código fechado.
John-David Dalton, autor do lodash, [escreveu isto no ano passado][1]:
Na reescrita do lodash, estou declarando falência da dívida técnica. Começando do zero com TypeScript e Rollup. Sem wrapper FP. Essa moda acabou. Meus pêsames aos colegas de quem trouxe essa dor de cabeça para o codebase. Não é nada amigável para equipes nem para pessoas.
Não sei se vai ser 100% assim, mas parece bem próximo.
[1]: https://twitter.com/jdalton/status/1571863497969119238
“Essa moda acabou. Meus pêsames aos colegas de quem trouxe essa dor de cabeça para o codebase. Não é nada amigável para equipes nem para pessoas.” Mas o autor original não era ele mesmo?
Soa como se outra pessoa tivesse acrescentado a complexidade que ele está criticando. Se foi ele quem introduziu isso, em vez de falar como uma retrospectiva ou aprendizado, parece que está dizendo que desenvolveu o projeto seguindo uma moda e que agora, como essa moda acabou, é hora de passar para a próxima.
O que era o wrapper FP e que moda era essa?
Não conheço bem as issues do lado JavaScript, então, neste contexto, qual é o problema da programação funcional?
Mandou bem
Só olhando alguns PRs no início da lista, há coisas como:
adicionar uma palavra em um comentário, adicionar um arquivo de configuração para promover um serviço de desenvolvimento, trocar var por let, mudar o comportamento bem estabelecido de uma função central, remover ponto e vírgula etc.
A maioria provavelmente foi aberta com boas intenções, para melhorar a biblioteca, mas em algum momento, para o mantenedor, isso simplesmente vira spam; ou, pior, uma carga que aumenta a culpa quanto mais ele não consegue dar atenção
Assim como celebridades contratam seguranças e voam de primeira classe ou em jatos particulares para fugir da atenção constante e preservar a sanidade, fico pensando que medidas seriam possíveis para projetos open source famosos
Pessoalmente, como mantenedor de open source, meus PRs favoritos são correções de typos, ajustes de texto e refatorações automáticas. Exigem quase nenhum esforço de revisão, então quase sempre faço o merge muito rápido
O que leva mais tempo são PRs que implementam funcionalidades enormes. Eles exigem muita revisão e discussão, então acabo adiando uma análise mais detalhada
Por um tempo houve uma moda de abrir PRs triviais em projetos famosos. Vejo isso como uma tentativa de rechear o currículo
Havia um usuário específico do GitHub que enviava repetidamente PRs para vários projetos JavaScript apenas trocando var por let
Parecia algo para preencher o perfil do GitHub
Uau
Eu estava começando a ficar interessado em migrar meu pacote para Bun, mas hesitava por preocupação com compatibilidade e com a possibilidade de o Bun realmente continuar existindo. Também já me queimei um pouco com o “Modern Yarn”. Mas, vendo o lodash migrar, agora tenho vontade de avaliar isso com mais seriedade
Isso é mesmo uma notícia grande. Especialmente considerando que, apesar do lançamento recente da v1.0, ainda há problemas de desempenho no Windows
Tento evitar dizer a desenvolvedores open source como eles devem tocar seus projetos. Também sou desenvolvedor open source, e fico irritado quando fazem isso comigo
Mas, se eu fosse um usuário que dedicou bastante tempo a abrir issues e ajudar a resolver problemas, ou alguém que trabalhou em uma correção ou novo recurso e enviou um PR, acho que agora eu estaria bem desmotivado
Mas a maioria dos usuários gasta só um tempo trivial abrindo issues. A maioria dos relatórios de bug é péssima
As issues foram fechadas, não desapareceram. Se ainda forem relevantes, parece que poderão ser solicitadas de novo mais tarde
A falência de issues é real. Falando por experiência pessoal, em algum momento manter open source fica difícil de conciliar com viver no mundo real
O trabalho é gratuito e muitas vezes não é agradecido. Claro, nem sempre é assim. Os problemas são complexos e competem com responsabilidades reais como trabalho, família e descanso. As pessoas se irritam com facilidade e regularmente querem discutir ou que você leia a documentação por elas. Quando o open source é famoso, vem junto uma responsabilidade enorme
Prevejo que haverá um grande colapso no ecossistema open source quando as pessoas que lideram projetos disserem “chega” e forem embora cuidar de coisas mais importantes
Eu entendo isso. Hoje em dia chego a pensar que projetos pessoais não triviais estão mais próximos de vício ou automutilação do que de projetos de verdade
Dito isso, o ecossistema open source é absurdamente ineficiente. Existem lodash, underscore e inúmeras outras bibliotecas, mas nem todas precisam existir. Há também muitas bibliotecas que fazem uma coisa só e, em geral, são subconjuntos dessas bibliotecas
A maior parte disso é usada junto com minificadores e tree shaking, e os recursos não utilizados são removidos. Mesmo bibliotecas pesadas são facilmente otimizadas e compostas em grande parte por partes separadas, então não há tanta necessidade de bibliotecas leves, e o esforço de desenvolvimento costuma crescer de forma linear
Se não fosse pelo fato de programadores gostarem acima de tudo de elegância e simplicidade, e de sempre quererem reescrever tudo para deixar um pouquinho melhor, acho que, se todos gastassem apenas um quarto do tempo que gastam hoje, ainda haveria gente suficiente no open source
Lodash é uma excelente biblioteca. Acabo usando um pouco dela em quase todos os projetos em que trabalho
Mas, à medida que JavaScript fica cada vez melhor, a quantidade de Lodash que uso vai diminuindo. Sempre que vou usá-la, verifico se há um recurso nativo para o que quero fazer. Também comento com certa frequência em PRs, com um link dizendo “isso não precisa de Lodash”
Ainda assim, espero que isso não seja um sinal de que o projeto está sendo abandonado
Com certeza é conveniente, mas, no fim, se eu precisar de utilitários, acho que vou preferir uma versão feita por mim
Não uso lodash nem underscore.js há 8 anos. Não sei bem o que existe que não dê para fazer facilmente com map, filter, find etc.
Um rastreador de issues tem dois usos sobrepostos. Um é uma forma de acompanhar o trabalho que os mantenedores precisam fazer, e o outro é uma forma de a comunidade mais ampla e os usuários acompanharem defeitos no software
Declarar “falência de issues” faz sentido para o primeiro uso, mas, no segundo, apaga informações valiosas sobre issues que existem na versão atual
1 comentários
Opiniões do Hacker News
Isto é realmente ambivalente. Por um lado, é ótimo. Quem nunca passou por uma reunião de limpeza de backlog em que se vai raspando de cima para baixo, mesmo sabendo que nunca se vai chegar ao fim? A sensação é certamente miserável.
Por outro lado, as issues não desapareceram, só ganharam outro rótulo; e, se tudo é uma questão de tags e organização, talvez seja melhor deixar o fluxo seguir em vez de tentar controlar essa quase utopia de uma lista de issues perfeitamente vazia. Também deve haver vantagens claras em deixar essas anotações em um lugar visível. É parecido com aquela sensação, durante uma grande faxina, de decidir jogar algo fora, mas o inconsciente insistir que talvez seja necessário mais tarde.
Ainda assim, no geral sou a favor. No mínimo, deve trazer uma sensação de libertação e um efeito de recarga para novas issues.
Acho que teria sido mais limpo lançar primeiro a versão reescrita e depois fechar as issues antigas como deprecated. As issues do branch de reescrita poderiam ter sido separadas por tags de versão. Se elas forem fechadas antes de a nova versão estar pronta, colaboradores podem abrir novas issues na versão antiga sem saber que ela não recebe mais suporte.
Ainda assim, não é que ele esteja ignorando as issues e deixando problemas no codebase; o projeto inteiro está sendo renovado.
https://twitter.com/jdalton/status/1571863497969119238
Acho mais honesto o projeto reconhecer a existência das issues e mantê-las abertas. Do ponto de vista dos desenvolvedores, se a quantidade de issues incomoda, seria melhor usar filtros para ocultar issues antigas e sem importância.
jwz disse isto:
Especialmente se for um bug difícil ou complexo de reproduzir, nem é certo que o mantenedor consiga reproduzi-lo no próprio ambiente, e é bem provável que quem reportou esteja mais acostumado a observar esse bug.
Se houver uma equipe maior, ou se for um projeto associado a um serviço comercial, esse equilíbrio pode mudar um pouco.
O que se vê em muitos projetos livres/open source é que pouquíssimas pessoas querem arregaçar as mangas, mas ao mesmo tempo gastam bastante tempo informando o quanto o projeto é essencial para elas, fazendo exigências e dando muitas sugestões.
A maioria cria novas issues para comunicar listas de desejos ou deixa relatos de bug muito vagos. Alguns até entregam bons relatórios de bug, mas em geral a disposição para contribuir para por aí.
Pessoalmente, não tenho disposição para lidar diplomaticamente com a maioria dos comentários que aparecem com frequência, então não tenho o perfil para manter projetos.
Ainda assim, nas issues que eu reporto, sempre tento fazer minha parte: investigar a causa e, quando possível, enviar um PR corrigindo.
Se é um problema com o qual você realmente se importa, é preciso adicionar testes.
John-David Dalton, autor do lodash, [escreveu isto no ano passado][1]:
Soa como se outra pessoa tivesse acrescentado a complexidade que ele está criticando. Se foi ele quem introduziu isso, em vez de falar como uma retrospectiva ou aprendizado, parece que está dizendo que desenvolveu o projeto seguindo uma moda e que agora, como essa moda acabou, é hora de passar para a próxima.
Mandou bem
Só olhando alguns PRs no início da lista, há coisas como:
adicionar uma palavra em um comentário, adicionar um arquivo de configuração para promover um serviço de desenvolvimento, trocar
varporlet, mudar o comportamento bem estabelecido de uma função central, remover ponto e vírgula etc.A maioria provavelmente foi aberta com boas intenções, para melhorar a biblioteca, mas em algum momento, para o mantenedor, isso simplesmente vira spam; ou, pior, uma carga que aumenta a culpa quanto mais ele não consegue dar atenção
Assim como celebridades contratam seguranças e voam de primeira classe ou em jatos particulares para fugir da atenção constante e preservar a sanidade, fico pensando que medidas seriam possíveis para projetos open source famosos
O que leva mais tempo são PRs que implementam funcionalidades enormes. Eles exigem muita revisão e discussão, então acabo adiando uma análise mais detalhada
varporletParecia algo para preencher o perfil do GitHub
A notícia maior é que o Lodash vai migrar de Node.js para Bun: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
Eu estava começando a ficar interessado em migrar meu pacote para Bun, mas hesitava por preocupação com compatibilidade e com a possibilidade de o Bun realmente continuar existindo. Também já me queimei um pouco com o “Modern Yarn”. Mas, vendo o lodash migrar, agora tenho vontade de avaliar isso com mais seriedade
Tento evitar dizer a desenvolvedores open source como eles devem tocar seus projetos. Também sou desenvolvedor open source, e fico irritado quando fazem isso comigo
Mas, se eu fosse um usuário que dedicou bastante tempo a abrir issues e ajudar a resolver problemas, ou alguém que trabalhou em uma correção ou novo recurso e enviou um PR, acho que agora eu estaria bem desmotivado
Eles fecharam 363 issues com a tag
issue bankruptcy: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl...PRs também: 325 foram tratados da mesma forma: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...
A falência de issues é real. Falando por experiência pessoal, em algum momento manter open source fica difícil de conciliar com viver no mundo real
O trabalho é gratuito e muitas vezes não é agradecido. Claro, nem sempre é assim. Os problemas são complexos e competem com responsabilidades reais como trabalho, família e descanso. As pessoas se irritam com facilidade e regularmente querem discutir ou que você leia a documentação por elas. Quando o open source é famoso, vem junto uma responsabilidade enorme
Prevejo que haverá um grande colapso no ecossistema open source quando as pessoas que lideram projetos disserem “chega” e forem embora cuidar de coisas mais importantes
Dito isso, o ecossistema open source é absurdamente ineficiente. Existem lodash, underscore e inúmeras outras bibliotecas, mas nem todas precisam existir. Há também muitas bibliotecas que fazem uma coisa só e, em geral, são subconjuntos dessas bibliotecas
A maior parte disso é usada junto com minificadores e tree shaking, e os recursos não utilizados são removidos. Mesmo bibliotecas pesadas são facilmente otimizadas e compostas em grande parte por partes separadas, então não há tanta necessidade de bibliotecas leves, e o esforço de desenvolvimento costuma crescer de forma linear
Se não fosse pelo fato de programadores gostarem acima de tudo de elegância e simplicidade, e de sempre quererem reescrever tudo para deixar um pouquinho melhor, acho que, se todos gastassem apenas um quarto do tempo que gastam hoje, ainda haveria gente suficiente no open source
Lodash é uma excelente biblioteca. Acabo usando um pouco dela em quase todos os projetos em que trabalho
Mas, à medida que JavaScript fica cada vez melhor, a quantidade de Lodash que uso vai diminuindo. Sempre que vou usá-la, verifico se há um recurso nativo para o que quero fazer. Também comento com certa frequência em PRs, com um link dizendo “isso não precisa de Lodash”
Ainda assim, espero que isso não seja um sinal de que o projeto está sendo abandonado
..., já trouxe um efeito enorme. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Os helpers de iteradores também devem ser lançados em breve, o que vai ajudar bastante. Os helpers de iteradores assíncronos devem demorar um pouco mais. https://github.com/tc39/proposal-iterator-helpersAntigamente, parecia que eu precisava usar
.apply()várias vezes por semana para chamar funções de formas criativas na base de código em que trabalhava. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Agora isso desapareceu completamente, e acho que, se 50% dos membros da equipe souberem o que são.calle.apply, já seria mais ou menos issoO Chrome 117 inclui
Object.groupBy(), e isso deve ajudar muito a eliminar muitos dos últimos pontos que levavam ao uso de lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...map,filter,findetc.Um rastreador de issues tem dois usos sobrepostos. Um é uma forma de acompanhar o trabalho que os mantenedores precisam fazer, e o outro é uma forma de a comunidade mais ampla e os usuários acompanharem defeitos no software
Declarar “falência de issues” faz sentido para o primeiro uso, mas, no segundo, apaga informações valiosas sobre issues que existem na versão atual