Lo entiendo perfectamente.[1]. Me encanta Discourse y escribí esta publicación porque quiero que Discourse siga teniendo éxito.
Algo que he aprendido es que a las comunidades no les gustan los cambios, pero están mucho más abiertas a ellos si sienten que tienen capacidad de decisión. Hay innumerables formas de dar a las personas esa capacidad. Por ejemplo, el tutorial podría convertirse en publicaciones wiki para que personas como yo puedan actualizarlas. Implementar el plan ESR también ayuda, ya que da a las personas la opción de no hacer cambios de inmediato.[2]. Poder escribir sobre mi experiencia y que sea vista por quienes gestionan el proyecto de código abierto también ayuda. Especialmente porque las quejas que expresé se solucionaron en una noche. 
En “¿Escuchar a los usuarios es perjudicial?”,[3] Kathy Sierra escribió:
La mayoría de nosotros somos conscientes de que los grupos de enfoque son notoriamente ineficaces para muchas cosas, pero aún así asumimos que escuchar comentarios reales de usuarios reales es la mejor manera de impulsar nuevos productos y servicios, así como de mejorar lo que ya tenemos. Pero hay un gran problema con eso: ¡la gente no necesariamente sabe cómo pedir algo que nunca ha concebido! La mayoría de las personas hacen sugerencias basadas completamente en mejoras incrementales, mirando lo que existe y pensando en cómo podría ser mejor. Pero eso es bastante diferente a tener una visión de algo profundamente nuevo.
La verdadera innovación rara vez provendrá de lo que los usuarios dicen directamente.
Como dije, no soy desarrolladora frontend. No entiendo realmente por qué se hicieron estos cambios ni cómo me beneficiarán.[4]. Y está bien si, con el tiempo, hacen que Discourse sea mejor.
Aún así, puede ayudar a personas como yo a estar a bordo si puedo ver la visión con un poco más de claridad. Para este cambio, la propuesta es:
- una experiencia de desarrollo mucho mejor
- permitirá grandes mejoras de rendimiento en futuras versiones de Discourse
Suena bien, supongo. No noté particularmente el punto #1 y el #2 podría significar muchas cosas. Para mí, sería más efectivo algo así (y lo estoy inventando totalmente):
- Cuando convertimos los complementos oficiales de Discourse, descubrimos que se eliminaron X% de líneas de código. Al colocar la plantilla en el mismo archivo que el JavaScript, el código es más fácil de entender y modificar en el futuro.
- Configuramos una rama para probar la eliminación completa de Handlebars y descubrimos que ese cambio hizo que las cargas de página fueran X% más rápidas. Además, vimos una posible optimización que podría eliminar [algunos problemas que han planteado los usuarios].
Un poco más de detalle con el objetivo de educar a los no expertos ayuda mucho a mantener la confianza. Quizás no me gusten los cambios, pero ¿cómo puedo argumentar en contra de solucionar problemas reales que otros usuarios han enfrentado?
OpenSSL tiene una dinámica similar. Tenemos una Corporación (~15 personas) que vende contratos de soporte y una Fundación (10 personas, yo incluida) que se encarga de los intereses no comerciales. Nuestra documentación también se queda atrás. Mientras escribía la publicación original, noté que todavía tenemos referencias a funciones que se eliminaron el mes pasado. Estoy trabajando en una PR para eso. Además, hicimos algunos cambios que proyectos downstream han criticado duramente ↩︎
Menos útil para los autores de complementos que desean apoyar a comunidades que quieren mantenerse a la vanguardia. Pero será genial para mí, ya que creo que soy la única persona que usa mi complemento ↩︎
Su blog ha desaparecido de internet, pero hay un archivo PDF. ↩︎
No es que yo importe mucho en el esquema general de las cosas. Hablo de mí como representante de otras personas que dependen de Discourse. ¡Después de todo, me conozco mejor que la mayoría! ↩︎