Je rattrape juste ce fil de discussion — mais je pense certainement que la réponse est oui
En raison du succès de notre communauté d’entreprise (à la fois auprès de nos utilisateurs et au sein de notre entreprise), notre équipe de documentation nous a contactés pour nous demander si nous pouvions créer un système de commentaires pour l’ensemble de documentation.sailpoint.com. D’après ce que nous avons vu, nous serons en mesure de faire presque tout ce que nous voulons accomplir, au minimum :
Intégrer des commentaires (fonctionnalité d’intégration)
Nous voulons également utiliser différents utilisateurs pour publier et appliquer différents ensembles de balises, en fonction de l’intégration. Cette fonctionnalité arrive très bientôt :
À partir de là, tout le reste ce que l’équipe de documentation (et mon équipe) voulait se trouvait dans Discourse pour que nous puissions séparer efficacement cette expérience du reste de notre utilisation quotidienne du forum, tout en donnant aux gens la possibilité de commenter, d’être notifiés des réponses, etc.
Possibilité de désigner quels utilisateurs peuvent et ne peuvent pas commenter
Attribuer des modérateurs de catégorie aux sujets associés
Supprimer cette pléthore de catégories pour ces documents de notre site principal
catégorie non consultable
composant de thème utilisé pour la masquer de la liste des catégories principales
supprimé du résumé
ajouté aux catégories par défaut en sourdine
Commentaires supprimés après n jours
Quelques autres paramètres…
J’aimerais vraiment voir beaucoup des fonctionnalités mentionnées ici mises en œuvre, cependant !
L’objectif est-il de permettre aux utilisateurs de créer des commentaires sur https://documentation.sailpoint.com/, ou êtes-vous d’accord pour simplement intégrer les commentaires sur le site de documentation et demander aux utilisateurs de visiter votre site Discourse pour commenter les articles ?
Le premier est une fonctionnalité que j’accueillerais et que j’aimerais avoir (lisez : s’il vous plaît, construisez-la, CDCK), mais le second répond à nos exigences minimales, du moins.\n\nJ’explorerai en fait une idée dans un avenir proche pour que Discourse serve notre documentation markdown (non, pas dans des sujets, mais dans des documents de style markdown traditionnels) auquel cas les commentaires, et l’inscription pour les faire, seraient tout compris. Mais cette exploration n’a pas encore commencé.
Avec l’approche sur laquelle je travaille actuellement, il serait techniquement possible de générer des commentaires Discourse directement sur les pages MkDocs, mais cela nécessiterait l’utilisation d’un framework côté serveur (Remix, Rails, etc.) pour servir les pages MkDocs. Cela permettrait d’authentifier les utilisateurs (avec DiscourseConnect) sur le site de documentation et également d’utiliser une base de données en mémoire pour la mise en cache des commentaires précédemment renvoyés.
(Edit : pour être clair, je parle de l’utilisation de Discourse comme fournisseur d’identité pour le site Web, et non du site Web comme fournisseur d’identité pour Discourse. Cette dernière approche fonctionne, mais elle est trop inflexible pour la plupart des cas d’utilisation.)
Ce serait cependant un changement majeur à demander à votre équipe.
Je suis sûr que de votre point de vue, ce serait plus simple si cela était accompli entièrement à l’intérieur de Discourse, mais il est également possible d’utiliser Discourse comme système de gestion de contenu. Dans ce cas, la documentation markdown serait générée sous forme de sujets Discourse classiques. Les webhooks Discourse seraient utilisés pour déclencher la génération d’une page de documentation sur un site externe. C’est d’ailleurs la base du site de démonstration des commentaires Discourse que je mets en place.
Puisque ce sujet a été lié aujourd’hui, j’ai pensé que je devrais le mettre à jour avec les conclusions auxquelles je suis parvenu après avoir travaillé sur l’idée.
Je pense toujours que Discourse serait une bonne plateforme de commentaires pour les raisons que j’ai exposées dans le message initial.
En ce qui concerne la manière de procéder, je pense que le travail doit être effectué du côté de Discourse - idéalement en améliorant le script d’intégration des commentaires de Discourse. Cela pourrait être fait progressivement.
Il est techniquement possible d’utiliser Discourse comme serveur pour une plateforme de commentaires en effectuant tout le travail sur un client Discourse (par exemple, le plugin WP Discourse), mais en raison de la nécessité de gérer l’état entre le client et Discourse, et de contourner les problèmes de limitation de débit, cela devient un problème complexe. C’est certainement plus complexe que quelque chose dont je souhaite être responsable de la maintenance.
Quelques messages dans ce sujet ont indiqué que les gens seraient intéressés par la simple possibilité pour les utilisateurs de créer des commentaires Discourse sur un site de blog. De mon point de vue, ce n’est pas une excellente solution, mais elle peut être réalisée dès maintenant avec l’API Discourse. Là où les choses se compliquent, c’est en essayant de créer un système de commentaires complet, où les utilisateurs peuvent interagir avec les commentaires Discourse sur un site Web d’une manière similaire à la façon dont ils s’attendraient à interagir avec les commentaires sur un site d’actualités grand public typique.
Étant donné mon expérience avec ActivityPub et WP Discourse, je pense que les commentaires bidirectionnels via JavaScript intégré sont réalisables. Le script d’intégration contiendrait ce qui suit :
Un « lecture » non authentifié fonctionnant de manière similaire à l’intégration JavaScript actuelle (avec quelques optimisations).
Un client distant (c’est-à-dire le navigateur de l’utilisateur) enregistre un client de clé API utilisateur, spécifique à la session de l’utilisateur et stocke les détails pertinents dans le stockage local du navigateur.
L’utilisateur est invité à « Se connecter pour commenter ».
L’utilisateur s’authentifie (auprès de Discourse) pour récupérer une clé API utilisateur de session qui est stockée dans le stockage local du navigateur.
Chaque activité (commentaire, like, etc.) est directement publiée sur un point de terminaison dédié avec des protections, une gestion et une gestion des tâches appropriées.
Avec le bon budget, je pense que je pourrais rendre la v1 prête pour la production et intégrée à discourse/discourse en 6 à 8 mois. Suite à la sortie initiale, je pourrais faire ce qui suit :
Ajouter un support explicite pour Wordpress, Ghost et d’autres plateformes sélectionnées.
Essayez de le mettre en œuvre d’une manière qui ait du sens pour les utilisateurs non techniques. Les plateformes existantes comme Disqus et les commentaires Facebook offrent probablement de bons exemples.
Quelques options d’authentification supplémentaires :
le site client devient un client DiscourseConnect. C’est simple à mettre en œuvre, mais nécessite du code côté serveur supplémentaire pour le site client.
les utilisateurs se connectent directement à Discourse via l’iframe
Ma réticence à développer cela purement côté client venait de la prise en compte des problèmes du système fonctionnant à une échelle quelconque. Essentiellement, je devais mettre en file d’attente les requêtes API et gérer les réponses des requêtes mises en file d’attente. Cela ne me semblait pas assez robuste pour gérer, disons, 1000 utilisateurs simultanés. J’aurais des préoccupations similaires, mais pour des raisons différentes avec l’approche d’intégration JavaScript. Je soupçonne que ce serait beaucoup plus facile à gérer qu’à essayer de tout synchroniser côté client cependant.
J’ai réfléchi davantage à cela hier, car le sujet a été relancé (c’est pourquoi j’ai fini par poster ici). Je pense qu’une solution côté client uniquement (c’est-à-dire une intégration JavaScript) est la seule qui ait vraiment du sens ici. Sinon, nous parlons essentiellement d’un certain nombre d’implémentations spécifiques à la plateforme, chacune avec son propre ensemble de problèmes.
Vous avez raison sur le fait que la concurrence et la charge sont des problèmes. Il y a des problèmes importants de charge et de concurrence avec ActivityPub, car un seul message ActivityPub peut vous exposer à de nombreuses requêtes entrantes et sortantes vers et depuis le Fediverse. Dans ce contexte, cela pourrait en fait être légèrement plus facile car les clients distants sont contrôlés. De plus, dans ce cas, la concurrence et la charge ne sont vraiment des problèmes que côté serveur (c’est-à-dire côté Discourse), et, bien qu’ils soient des problèmes, je pense qu’ils devraient être résolubles via des tâches d’arrière-plan, la mise en cache et des mutex. Mais oui, ce sont des problèmes importants à considérer.
Pour être honnête, ma plus grande préoccupation ici est le calendrier.
Composer v2 est sur le point d’arriver, ce serait fou de se lancer dans cette aventure et de ne pas s’appuyer sur notre nouveau composer, mais il y a une montagne de travail dont nous avons besoin en amont pour rendre son utilisation dans une application légère réalisable.
Je pense que la bonne chose à faire ici est de surveiller cet espace pour le nouveau composer pendant environ 2 à 3 mois, puis de réexaminer la question.
Je pense que cela peut être fait en parallèle. Vous devez apporter 2 modifications au discours.
Le bouton « Répondre » doit être visible pour les utilisateurs non enregistrés.
Et lorsque les utilisateurs non enregistrés cliquent sur ce bouton, ceci devrait s’afficher :
Ensuite, vous devez déterminer comment utiliser l’insertion de commentaires. Il s’agira probablement de petites modifications de code plutôt que d’un travail considérable.
Je me demande s’il y a toujours de l’intérêt à développer cette fonctionnalité, maintenant que Composer v2 est sorti. Je vote pour que ce soit toujours quelque chose que j’aimerais voir et utiliser.
