#dusk $DUSK @Dusk No relatório semanal de desenvolvimento, a palavra mais fácil de ser interpretada de forma errada na verdade não é “novo”, e sim “já”. Agora que vejo o pessoal do grupo falando que, quando uma função de reescrita de uma linha de atualização para “atualização bem-sucedida” já foi colocada no ar, eles param um pouco antes de compartilhar—não estão com pressa de anunciar—porque a mesclagem de código, a conclusão dos testes e o fato de usuários comuns conseguirem acessar o ponto de entrada, de fato, não estão no mesmo estado. No @Dusk , ao ler os Developer Updates de 10 a 17 de agosto, minha avaliação mudou. A página primeiro limita o escopo: ela consolida as atividades de engenharia em repositórios públicos que atendem aos critérios nos sete dias anteriores. Ao lado do resumo, há as alterações públicas correspondentes. Nesta rodada, ainda foram adicionadas uma seção de atualizações e um índice com prioridade para o mais recente. Isso parece mais um índice de evidências do que um anúncio de produto. Cenários de pressão também são bem comuns: alguém captura uma linha “Added” e reformula como se certa capacidade já estivesse disponível; depois, quem chega depois vai procurar o ponto de entrada e descobre que talvez seja apenas uma mudança no nível de ferramenta, teste ou documentação. Ninguém precisa necessariamente estar mentindo, mas quando o avanço de engenharia é comprimido como uma promessa de produto, a decepção acaba recaindo sobre quem de fato está pronto para usar. Por isso, quando eu vejo @Dusk atualizando, eu sigo em duas etapas: primeiro, verificar o que as alterações públicas provam; depois, checar a documentação do usuário, o status da versão ou o acesso real ao ponto de entrada para confirmar quem consegue usar. @Dusk colocar o registro original ao lado da atualização é um bom começo. Ao divulgar, não deixe essa delimitação de fora—é mais perto da confiança que #dusk precisa.