C’est exactement le problème avec la documentation de Discourse.
Autant il peut être « acceptable » pour certains de devoir chercher des sujets, autant ce n’est pas de la documentation. C’est avoir les utilisateurs, et pire, les administrateurs/modérateurs qui doivent chercher l’information.
Non, ce n’est pas le cas. Et cela a été, et reste, le plus grand manque de Discourse. Je ne sais pas si je suis trop grossier maintenant ou quoi que ce soit, mais la tendance à agir ici est trop centrée sur le développeur — si vous ne savez pas, vous pouvez toujours lire le code source sur GitHub. CDCK n’a pas beaucoup de motivation pour commencer à construire une bonne documentation pour les utilisateurs — y compris les administrateurs, bien sûr — car leur cible sont les grandes entreprises hébergées. Donc, pour eux, un niveau minimum plus l’aide de la communauté pour les profiteurs (qui font une grande partie de la chasse aux bugs et des propositions d’expérience utilisateur 
) était suffisant. Sauf si nous avions alors besoin d’une utilisation plus libre des tags…
Était suffisant n’était pas juste une faute de frappe ou un faible niveau d’anglais. CDCK/l’équipe a commencé à construire une meilleure documentation et je suis totalement sûr qu’après un certain temps, des sujets secondaires comme celui-ci ne seront que des échos du passé.
En tant que communautés de développeurs/utilisateurs, Discourse est bien au-dessus de la moyenne. Les erreurs semblent être corrigées rapidement, les demandes de fonctionnalités ne sont pas simplement ignorées, surtout s’il existe un cas d’utilisation raisonnable pour elles, et le personnel en ligne (payé ou bénévoles, je ne suis pas sûr de savoir qui est qui) est plutôt bon et assez patient pour nous guider, nous les nouveaux.
Oui, la documentation a besoin d’être améliorée, mais écrire une bonne documentation est coûteux et prend du temps. De plus, les développeurs n’écrivent souvent pas une bonne documentation parce qu’ils sont trop proches du produit, ils ne le voient pas comme les utilisateurs le voient. Être trop proche du code est aussi un problème de test de produit, bien que dans de nombreux projets open source, la communauté d’utilisateurs fasse un bon travail de test.
Bien sûr. Écrire du bon code aussi. Le travail humain de bonne qualité est souvent cher. Mais le code et la documentation sont liés, et la documentation commence à coûter cher à ce moment-là quand personne ne la fait. Sinon, c’est juste une partie cruciale d’un produit, tout comme le codage, y compris les tests, la conception, l’UX/UI, etc. Mais les développeurs détestent souvent la documentation parce qu’ils détestent simplement la faire, il n’y a rien de sexy là-dedans, en plus ils sont souvent vraiment mauvais pour ça Mais comme les propriétaires d’entreprises, et d’autres superviseurs, sont des développeurs similaires, ils ne se soucient tout simplement pas que les gars choisissent ce qu’ils font et ce qu’ils ne font pas.
Mais maintenant, je dérive vers des choses trop générales qui sont beaucoup trop hors sujet. Je vais donc m’arrêter et pointer vers Documentation car elle évolue en ce moment.
Je suis tout à fait d’accord avec cela. Je suis un développeur avec plus de 20 ans d’expérience à ce stade, même si j’ai évolué vers l’ingénierie de plateforme ces dernières années.
C’est très clair ici lorsque vous demandez une suggestion et que des développeurs (je suppose ? Je ne vois que leur titre fait partie de discourse lui-même) viennent vous dire que ce n’est pas et ne sera pas parce qu’ils l’ont décidé.
Hors sujet à partir d’ici
Je l’ai déjà dit : il y a une différence entre avoir des opinions sur votre pile technologique et avoir des opinions sur votre produit. Votre produit doit répondre aux cas d’utilisation des utilisateurs, dans la limite du raisonnable, et non pas être « mon ballon et si les autres n’aiment pas, ils peuvent aller ailleurs ».
J’ai déjà démarré 5 nouveaux projets et grâce au ciel, nous avons eu quelqu’un dans notre communauté qui connaît un peu Ruby et qui va nous expliquer quelques bases du flux de discourse dans les prochains jours afin que nous puissions commencer à écrire des plugins qui fournissent les fonctionnalités dont nous avons besoin. L’une d’elles avant tout, faire en sorte que les Category Mods ne soient pas une blague.
Le sujet de support Users are receiving emails even when everything is set up to not send email notifications a un peu évolué, je l’ai donc divisé en quelques nouveaux sujets dans d’autres catégories pour leur donner de l’espace pour respirer. 
Je peux penser à un projet open source où les développeurs ont tendance à travailler sur des choses qui les intéressent, et non sur des choses qui pourraient faciliter la vie des utilisateurs de ce produit. Le cas d’utilisation est toujours une question de perspective, les utilisateurs des produits ont une vision différente du cas d’utilisation que les développeurs. Les développeurs ont tendance à considérer ce que font les utilisateurs comme « juste plus de données », et ne voient souvent pas comment un petit changement pourrait faire une ÉNORME différence en termes d’utilisabilité. (J’ai fait ma part de développement de systèmes, et je suis sûr que j’ai eu cette attitude à certains moments.)
Jusqu’à présent, je ne peux pas dire que j’ai vu ce genre d’attitude avec le développement de Discourse, mais je ne suis là que depuis un mois.
Quant à être trop proche du produit, je suis actuellement en train de faire les exercices d’un livre sur le développement Ruby. Une simple application « hello world » m’a pris 3 heures pour fonctionner hier, principalement parce que le livre supposait une familiarité avec un environnement AWS IDE (cloud9) que je n’avais pas encore, donc je cliquais sur quelque chose et cela annulait les changements que je venais de passer 10 minutes à taper.
Et puis il y a eu un problème pour afficher un aperçu de l’application en cours de fonctionnement dans mon navigateur, ce qui semble être dû à des limitations de sécurité que Firefox et Chrome ont mises dans leurs navigateurs depuis la dernière mise à jour du livre. Après environ une heure de recherche de solutions sur le Web, la mise sur liste blanche de l’adresse IP de mon ordinateur portable et de mon ordinateur de bureau a fonctionné, bien que je doive encore passer par une étape supplémentaire pour afficher l’aperçu.