Merci ! Cela aide vraiment et réduit la panique.
Mais :
sont toujours des points très valables.
Je pense que beaucoup d’entre nous ne soutiennent pas que « telle fonctionnalité » doive ou ne doive pas être prise en charge par « telle version » pendant « telle durée », mais que Discourse devrait offrir une dégradation gracieuse, peut-être un mode HTML simple + HTTP POST comme les premiers forums. Idéalement, cela serait prioritaire sur les nouvelles fonctionnalités, surtout sur les changements cosmétiques, mais je dirais aussi sur les optimisations de performance.
Les utilisateurs de Discourse ne devraient pas avoir à choisir entre la communauté et les nouvelles fonctionnalités — et cette partie semble être une question culturelle. Il semble que les développeurs veuillent « avancer un peu vite, pas trop vite, casser quelques trucs mais pas trop ». C’est peut-être une position tout à fait raisonnable pour une entreprise de logiciels, mais ce n’est pas nécessairement la même position que souhaiteraient les communautés Discourse. Certaines communautés voudraient avancer plus vite tandis que d’autres préféreraient beaucoup plus lentement, voire pas du tout.
Pour moi, Discourse est déjà « assez bon » aujourd’hui et s’il y avait une option pour les clients hébergés de choisir une branche de support à long terme sans nouvelles fonctionnalités ajoutées pendant les 10 prochaines années, seulement des correctifs de sécurité critiques, je la choisirais totalement — même si la nouvelle version était 10 fois plus rapide. Je préférerais de loin un forum lent que tout le monde peut utiliser plutôt qu’un forum qui perd progressivement des utilisateurs juste pour offrir une expérience plus rapide et plus brillante aux survivants.
Mais tout le monde ne serait pas d’accord. Ce rythme serait beaucoup trop lent pour les développeurs (je présume) et pour d’autres communautés Discourse… cela dépend totalement de leurs utilisateurs et de leurs données démographiques d’appareils. Un forum pour personnes âgées ne poursuivra jamais les mêmes fonctionnalités qu’un forum d’IA, par exemple.
Mais ils ne devraient pas avoir besoin de se battre ainsi. Ce ne sont pas des objectifs mutuellement exclusifs. La dégradation gracieuse est un principe de base depuis les débuts du web, et Discourse est déjà suffisamment headless (avec diverses API, et aussi prouvé par des implémentations tierces comme Discorkie) qu’il devrait être possible de fournir un mode « HTML simple » avec lecture + publication de base. Il n’a pas besoin de thèmes fantaisistes, il n’a pas besoin de pagination infinie, il n’a même pas nécessairement besoin d’édition, de notifications et de toutes ces autres fonctionnalités souhaitables. Il doit juste être une expérience de base utilisable qui permet aux gens d’utiliser encore le forum pour sa fonction prévue, lire et publier. Il peut n’offrir rien de plus qu’une expérience utilisateur de style Usenet des années 90 et ce serait toujours mieux que de couper complètement les gens. Avec un peu plus de temps de développement, il pourrait offrir une interface utilisateur de l’ère PHP de style vBulletin et ce serait toujours une énorme amélioration par rapport à la situation « Désolé, vous ne pouvez plus publier » (que nous verrons encore en juillet).
À mon avis, Discourse est (ou devrait être) avant tout une question de communauté. Ce n’est plus une démo technique, et bien que ma préférence personnelle soit qu’il soit considéré comme un « logiciel stable et ennuyeux » qui change rarement, voire jamais… Je comprends que ce n’est peut-être pas ce que les développeurs et d’autres communautés Discourse souhaitent. Ce n’est pas grave. Ce n’est pas un système bancaire 
Mais inversement, il n’a pas besoin de suivre les améliorations constantes des navigateurs (qui ne finiront jamais). Entre les deux extrêmes, un mode HTML de base permettrait aux utilisateurs de continuer à publier bien après que leurs navigateurs soient obsolètes, tout en permettant un développement de fonctionnalités plus rapide sur la branche principale car les utilisateurs auront quelque chose sur quoi se rabattre.
En prime, cela pourrait vous permettre de cibler le type de développement basé sur des fenêtres temporelles que vous souhaitez effectuer (par exemple, « nous prendrons en charge les navigateurs jusqu’à 2 ans d’ancienneté, ou la marque 95% caniuse ») plutôt que de sélectionner individuellement des fonctionnalités sur toutes les permutations possibles de matériel + OS + navigateur + fork. Tout ce qui est plus ancien que cette cible pourra toujours publier via le mode HTML de base, mais ne pourra pas utiliser les derniers thèmes, _____, ______, _____ etc. (ce qui est tout à fait normal car ils ne s’en soucient probablement pas de toute façon). Cela vous évite d’avoir à vérifier chaque fonctionnalité par rapport à chaque navigateur… si un utilisateur ne peut pas utiliser une fonctionnalité fantaisiste, eh bien, ce serait vraiment à lui de mettre à niveau vers un nouveau navigateur. Mais au moins, il ne serait pas expulsé de ses communautés.