Este es exactamente el problema con la documentación de Discourse.
Por mucho que pueda estar “bien” que algunos busquen temas, no es documentación. Significa que los usuarios, y lo que es peor, los administradores/moderadores tienen que buscar información.
No, no lo es. Y esa ha sido, y sigue siendo, la mayor carencia de Discourse. No sé si soy demasiado grosero ahora o algo así, pero la tendencia de actuar aquí es demasiado centrada en el desarrollador: si no lo sabes, siempre puedes leer el código fuente en GitHub. CDCK no tiene demasiada motivación para empezar a construir una buena documentación para los usuarios —incluidos los administradores, por supuesto— porque su objetivo son las grandes corporaciones alojadas. Así que para ellos, el nivel mínimo más la ayuda de la comunidad para los que van por libre (¡que hacen una gran parte de la búsqueda de errores y las propuestas de UX!) era suficiente. Excepto que entonces necesitaríamos un uso más libre de las etiquetas…
Era suficiente no fue solo un error tipográfico o una baja habilidad en inglés. CDCK/el equipo ha empezado a construir una mejor documentación y estoy totalmente seguro de que después de algún tiempo, temas secundarios como este serán solo ecos del pasado.
Como comunidades de desarrolladores/usuarios, Discourse está muy por encima del promedio. Los errores parecen corregirse rápidamente, las solicitudes de funciones no se ignoran, especialmente si tienen un caso de uso razonable, y el personal en línea (pagado o voluntario, no estoy seguro de cómo se distingue quién es quién) es bastante bueno y bastante paciente para guiar a los novatos como nosotros.
Sí, la documentación necesita trabajo, pero escribir buena documentación es caro y requiere mucho tiempo. Además, los desarrolladores a menudo no escriben buena documentación porque están demasiado cerca del producto, no lo ven como lo ven los usuarios. Estar demasiado cerca del código también es un problema de prueba de producto, aunque en muchos proyectos de código abierto la comunidad de usuarios hace un buen trabajo probando las cosas.
Claro que sí. Escribir buen código también lo es. El trabajo humano de buena calidad suele ser caro. Pero el código y la documentación están ligados, y la documentación empieza a ser cara en el punto en que nadie la hace. De lo contrario, es solo una parte crucial de un producto como lo es la codificación, incluyendo pruebas, diseño, UX/UI, etc. Pero a los desarrolladores a menudo les desagrada la documentación porque simplemente odian hacerla, no tiene nada de sexy, además de que suelen ser bastante malos en ello 
Pero como los dueños de las empresas, y otros supervisores, son desarrolladores similares, simplemente no les importa que los chicos seleccionen lo que hacen y lo que no.
Pero ahora me estoy desviando a cosas demasiado generales que están muy fuera de tema. Así que me iré y señalaré a Documentation porque está evolucionando ahora mismo.
Estoy totalmente de acuerdo con esto. Soy un desarrollador con más de 20 años de experiencia en este momento, incluso si me he dedicado a la ingeniería de plataformas en los últimos años.
Eso está muy claro aquí cuando pides una sugerencia y los desarrolladores (¿supongo? Solo puedo ver que son parte de discourse en su título) vienen y te dicen que no es y no será porque ellos lo decidieron así.
Fuera de tema
Ya he dicho esto: hay una diferencia entre tener una opinión firme sobre tu pila tecnológica y tener una opinión firme sobre tu producto. Tu producto debe adaptarse a los casos de uso de los usuarios, dentro de lo razonable, no ser “mi pelota y si a otros no les gusta, pueden ir a otra parte”.
Ya he iniciado 5 proyectos nuevos y, gracias a Dios, teníamos a alguien en nuestra comunidad que sabía un poco sobre Ruby y nos explicará algunos conceptos básicos del flujo de discourse en los próximos días para que podamos comenzar a escribir algunos complementos que proporcionen las funciones que necesitamos. Sobre todo, hacer que los Moderadores de Categoría no sean una broma.
El tema de soporte Users are receiving emails even when everything is set up to not send email notifications ha evolucionado un poco, así que lo he dividido en un par de temas nuevos en otras categorías para darles a cada uno un poco de espacio para respirar. 
Se me ocurre un proyecto de código abierto en el que los desarrolladores tienden a trabajar en cosas que les interesan, no en cosas que podrían facilitar la vida de los usuarios de ese producto. El caso de uso siempre es una cuestión de perspectiva, los usuarios de los productos tienen una visión del caso de uso diferente a la de los desarrolladores. Los desarrolladores tienden a pensar en las cosas que hacen los usuarios como “simplemente más datos”, y a menudo no ven cómo un pequeño cambio podría marcar una GRAN diferencia en la usabilidad. (He hecho mi parte de desarrollo de sistemas, y estoy seguro de que he tenido esa actitud en ocasiones).
Hasta ahora, no puedo decir que haya visto ese tipo de actitud con el desarrollo de Discourse, pero solo llevo un mes aquí.
En cuanto a estar demasiado cerca del producto, actualmente estoy repasando los ejercicios de un libro sobre desarrollo de Ruby. Una simple aplicación de “hola mundo” me llevó 3 horas para que funcionara ayer, principalmente porque el libro asumía familiaridad con un entorno de IDE de AWS (cloud9) que aún no tenía, así que hacía clic en algo y deshacía los cambios que acababa de pasar 10 minutos escribiendo.
Y luego hubo un problema para que se mostrara una vista previa de la aplicación en funcionamiento en mi navegador, lo que parece deberse a limitaciones de seguridad que tanto Firefox como Chrome han implementado en sus navegadores desde la última actualización del libro. Después de aproximadamente una hora de búsqueda de soluciones en la web, la lista blanca de la dirección IP de mi portátil y mi escritorio funcionó, aunque todavía tengo que pasar por un paso adicional para que se muestre la vista previa.