Entendo perfeitamente.[1] Eu realmente gosto do Discourse e escrevi este post porque quero que o Discourse tenha sucesso contínuo.
Uma coisa que aprendi é que as comunidades não gostam de mudanças, mas estão muito mais abertas a elas se sentirem que têm agência. Existem inúmeras maneiras de dar agência às pessoas. Por exemplo, o tutorial poderia ser transformado em posts de wiki para que pessoas como eu possam atualizá-los. Implementar o plano ESR também ajuda, pois dá às pessoas a opção de não fazer mudanças imediatamente.^[Menos útil para autores de plugins que desejam apoiar comunidades que querem permanecer na vanguarda. Mas será ótimo para mim, já que acredito que sou a única pessoa usando meu plugin.) Poder registrar minha experiência e ter isso visto por pessoas que gerenciam o projeto de código aberto também ajuda. Especialmente porque as coisas das quais reclamei foram corrigidas durante a noite. 
Em “Escutar usuários é prejudicial?”,[2] Kathy Sierra escreveu:
A maioria de nós percebe que grupos de foco são notoriamente ineficazes para muitas coisas, mas ainda assumimos que ouvir feedback real de usuários reais é a melhor maneira de impulsionar novos produtos e serviços, bem como melhorar o que já temos. Mas há um grande problema nisso – as pessoas não necessariamente sabem como pedir algo que nunca conceberam! A maioria das pessoas faz sugestões baseadas inteiramente em melhorias incrementais, olhando para o que existe e pensando em como poderia ser melhor. Mas isso é bastante diferente de ter uma visão para algo profundamente novo.
A verdadeira inovação raramente virá do que os usuários dizem diretamente.
Como disse, não sou desenvolvedor frontend. Não entendo muito bem por que essas mudanças foram feitas ou como elas me beneficiarão.[3] E isso é ok se, eventualmente, elas tornarem o Discourse melhor.
Ainda assim, pode ajudar pessoas como eu a ficarem a bordo se eu puder ver a visão um pouco mais claramente. Para essa mudança, a proposta é:
- uma experiência de desenvolvimento muito melhor
- permitirá grandes melhorias de desempenho em futuras versões do Discourse
Parece bom, suponho? Eu não percebi particularmente o #1 e o #2 poderiam significar muitas coisas. Seria mais eficaz para mim algo como (e estou totalmente inventando isso):
- Quando convertemos os plugins oficiais do Discourse, descobrimos que isso reduziu X% das linhas de código. Ao colocar o template no mesmo arquivo que o JavaScript, o código fica mais fácil de entender e modificar no futuro.
- Criamos uma branch testando a remoção completa do Handlebars e descobrimos que essa mudança tornou o carregamento das páginas X% mais rápido. Além disso, identificamos uma otimização potencial que poderia eliminar [algum problema que os usuários levantaram].
Um pouco mais de detalhes com foco em educar não especialistas vai longe para manter a confiança. Eu posso não gostar das mudanças, mas como posso argumentar contra a correção de problemas reais que outros usuários enfrentaram?
O OpenSSL tem uma dinâmica similar. Temos uma Corporação (~15 pessoas) que vende contratos de suporte e uma Fundação (10 pessoas, incluindo eu) que cuida dos interesses não comerciais. Nossa documentação também fica defasada. Enquanto escrevia o post original, notei que ainda temos referências a recursos que foram removidos no mês passado. Estou trabalhando em um PR para isso. E fizemos algumas mudanças que projetos downstream foram altamente críticos. ↩︎
O blog dela sumiu da internet, mas há um arquivo PDF. ↩︎
Não que eu realmente importe tanto assim na grande esquema das coisas. Estou falando de mim como representante de outras pessoas que dependem do Discourse. Afinal, conheço a mim mesmo melhor do que a maioria! ↩︎