Recherche et liaison de sujets en ligne, par exemple liens entre crochets de type Roam

Je pense qu’il est temps que Discourse propose un moyen plus rapide de créer des liens vers d’autres sujets sur un forum donné. Bien sûr, il existe déjà le bouton de lien et le raccourci dans l’éditeur, et si vous êtes vraiment brillant et que vous connaissez l’URL exacte d’un sujet, vous pouvez même le faire sans utiliser la boîte de dialogue de lien. Mais d’autres applications montrent qu’il existe une méthode meilleure, plus rapide et plus simple : invoquer une boîte de dialogue de recherche et de lien directement dans le texte.

Il existe déjà un précédent dans Discourse avec le comportement de recherche et de lien via @ pour les profils, ainsi que # pour les hashtags. Je propose donc simplement d’ajouter la recherche et le lien pour les sujets. Cela adopterait une approche très minimaliste, similaire à la recherche d’utilisateurs via @, avec une recherche rapide de sujets en ligne dans une fenêtre contextuelle basée sur le texte que vous tapez dans l’éditeur, et sans aucun champ pour le titre ou d’autres contrôles. Cela fonctionnerait exactement comme la recherche @, mais pour les liens. Vous utiliseriez le clavier pour confirmer le lien, et la première option serait automatiquement mise en surbrillance.

Une syntaxe récemment popularisée pour cela est les « liens entre crochets », c’est-à-dire [[lien-vers-sujet]]. Vous tapez [[ et une recherche des titres de sujets est lancée, tout comme pour les recherches d’utilisateurs ou de hashtags. Une autre approche courante est le menu slash /, bien qu’il soit généralement utilisé pour plusieurs fonctions. Quelle que soit la méthode d’invoquation, cela rendrait la création de liens entre sujets extrêmement rapide et facile, ce que je considère personnellement comme une bonne chose car cela encourage les gens à référencer d’autres contenus existants et apparentés.

Le principal problème que je vois avec cette syntaxe particulière est qu’elle diffère de la syntaxe wiki actuellement prise en charge, tout en lui étant similaire. Cependant, la syntaxe des liens wiki est en fait utilisée dans des systèmes qui prennent également en charge la syntaxe à double crochet [], mais spécifiquement pour les liens nécessitant un texte personnalisé. Une option serait donc d’utiliser cette même distinction : des doubles crochets pour un lien vers un sujet utilisant le titre du sujet comme texte du lien, ou un lien wiki traditionnel pour un titre personnalisé. Une autre serait de changer la syntaxe des liens dans son ensemble, ce que je doute être attrayant. Une troisième option consisterait à choisir une autre syntaxe de lien en ligne, c’est-à-dire un autre ensemble de caractères pour invoquer la recherche de liens.

Je ne me soucie pas vraiment de la manière exacte dont cela sera implémenté, je veux simplement pouvoir rechercher et lier directement dans le texte ! Je pense que ce serait un excellent ajout à l’éditeur déjà excellent de Discourse et à ses fonctionnalités de commodité générales. :slight_smile:

Cela dit, je réalise que les fonctions existantes de l’éditeur sont tout à fait bonnes et qu’il s’agit seulement d’une fonctionnalité de commodité, arguablement pour un certain sous-ensemble d’utilisateurs. C’est définitivement une priorité basse, même s’il y a accord sur le fait que ce serait utile.

6 « J'aime »

Quelque chose de similaire existe lorsque vous sélectionnez et déplacez des messages vers un nouveau/sujet existant. Franchement, c’est une corvée dans sa forme actuelle :

  • la recherche prend beaucoup de temps
  • même si vous connaissez le titre du sujet et que vous le tapez exactement tel quel (respect de la casse, etc.), la recherche ne trouve pas le sujet souhaité
  • la recherche le trouve, vous le sélectionnez, puis la recherche reprend avant même que vous ayez la possibilité de confirmer votre sélection. Votre sélection disparaît, la recherche ne liste même plus le sujet que vous aviez choisi

Mon expérience est tout l’inverse, voir ci-dessus.
Je trouve plus rapidement le bon sujet en utilisant la fonction de recherche standard.

1 « J'aime »

Bonjour Oshyan, :slightly_smiling_face:

J’aime beaucoup l’idée, mais…

Le titre du sujet n’est pas unique. Ainsi, lorsque vous recherchez un sujet, vous avez désormais des informations supplémentaires telles que des tags et des catégories pour mieux l’identifier. Cependant, l’affichage en ligne pourrait être trop encombré, et il arrive que trop de sujets correspondent à votre recherche pour permettre un filtrage efficace directement dans la ligne de saisie.

Autre point :
Lorsque vous utilisez ce panneau pour insérer un lien, vous devez confirmer votre choix en cliquant sur un bouton, ce qui me semble très utile.

En mode inline, si vous manquez le bon sujet, vous devez effacer beaucoup de texte, et il y a peut-être davantage de liens au format brisé qu’actuellement.

Il existe peut-être une bonne façon de rendre cela simple et rapide, mais pour l’instant, je pense que la solution avec le panneau est plus rapide et plus conviviale.

1 « J'aime »

Tout cela semble résulter de défaillances de l’interface utilisateur (UI/UX) ou des fonctions de recherche, et non d’un problème inhérent à l’idée du lien intégré en soi. Si ce n’est pas déjà fait, je vous suggère d’ouvrir un sujet pour discuter des améliorations ou des correctifs concernant le comportement actuel de « déplacer les messages/fusionner », compte tenu des expériences que vous décrivez. Mais en supposant que ce type de problème ne se produise pas dans le contexte de ma proposition de méthode de lien, le trouveriez-vous alors utile ?

Pourquoi supposez-vous que la recherche en ligne fonctionnerait différemment de la recherche basée sur la barre d’outils ? En ce qui concerne le comportement de recherche et d’affichage, cela devrait fonctionner exactement de la même manière, offrant ainsi le même niveau de facilité et d’utilité pour trouver et sélectionner le bon sujet. Ma préférence serait qu’elle se distingue du dialogue de lien existant et se concentre sur la rapidité et la facilité d’utilisation, fonctionnant de manière très similaire à la recherche @ existante qui fait apparaître une petite liste de résultats contextuels. La liste des résultats pourrait ressembler exactement à celle du dialogue de lien, mais je ne veux pas de champ de titre de sujet, de bouton OK/annuler, etc. Il existe déjà un raccourci qui l’ouvre.

Je ne vois vraiment pas pourquoi il y aurait plus de liens cassés. Vous devez toujours appuyer sur Entrée pour confirmer le sujet que vous avez sélectionné dans la recherche.

Eh bien, ce n’est certainement pas « plus rapide ». Cela peut être plus convivial, certes, mais ma suggestion n’est pas de remplacer le lien de la barre d’outils existant, mais simplement d’ajouter un moyen plus rapide de lier pour les utilisateurs plus expérimentés.

Je suppose que Ctrl-K (raccourci) est une bonne alternative et existe déjà, bien sûr. J’aime simplement la possibilité d’utiliser la syntaxe en ligne pour déclencher des choses utiles, et c’est quelque chose que Discourse adopte déjà avec @ et #. Ces deux fonctions pourraient également être accessibles via des raccourcis clavier ou une saisie manuelle sans recherche, mais bien sûr, il y a une valeur ajoutée dans leur fonctionnement actuel. Je propose que le lien puisse gagner une valeur similaire avec cette approche.

2 « J'aime »

Ah d’accord, je comprends, merci pour les précisions !
Ce serait une fonctionnalité avancée qui conserverait le panneau de recherche original.
Ça me semble être une bonne idée. :slightly_smiling_face:

1 « J'aime »

Pour plus de clarté, voici ce que nous avons aujourd’hui :

CTRLALTf
rechercher un élément
FLÈCHE VERS LE BAS
a

Par exemple : In-line topic search-and-linking, e.g. Roam-like bracket links

Le problème est que c’est extrêmement difficile à expliquer, mais cela offre (selon certains) un ensemble de fonctionnalités plus vaste que la proposition [[.

5 « J'aime »

Oh, c’est très intéressant et bon à savoir ! Cependant, je pense qu’il existe une différence importante entre la syntaxe d’action intégrée et la commande d’action via clavier. La découvrabilité en est une, la vitesse en est une autre.

Il est vrai que, une fois appris, l’utilisation de cette séquence est raisonnablement rapide, mais après l’avoir essayée à plusieurs reprises pour tester, elle semble certainement plus lente et moins fluide que mon expérience dans le (nombre croissant de) applications qui prennent en charge les liens entre crochets []. Cela tient peut-être en partie au fait que cela implique un déplacement de l’attention et du regard, en plus du raccourci clavier nouveau et légèrement malcommode. Ce dernier pourrait être partiellement surmonté avec le temps (bien que la géométrie de base de ma main impose certaines limites à ce potentiel), mais le déplacement de l’attention aura toujours un coût lors de la rédaction d’un message.

Il est d’ailleurs intéressant pour moi que vous ayez eu suffisamment envie de liens rapides pour créer cette séquence de raccourci clavier quelque peu inhabituelle (sans doute parce que beaucoup d’autres étaient déjà utilisés). Cela suggère un peu que vous pourriez voir une certaine valeur dans l’idée des liens intégrés en général… Mais j’ai l’impression qu’il n’y a pas beaucoup de soutien pour ma suggestion pour le moment. Même ainsi, je suis curieux de savoir s’il existe des obstacles clairs à cela, par exemple : « Nous utilisons les crochets pour autre chose », « nous ne pouvons pas ajouter un autre gestionnaire intégré sans ralentir toutes les requêtes de base de données de 30 % » ou autre chose du genre. :grinning_face_with_smiling_eyes:

En tout cas, j’espère que cela a au moins piqué l’intérêt de quelqu’un. J’aimerais toujours que cette fonctionnalité soit disponible, et je suppose que, une fois que d’autres utilisateurs auront eu l’occasion de l’essayer, ils pourraient aussi l’adorer (y a-t-il des utilisateurs de Roam ici ? D’Obsidian ? De Logseq ?). Mais au minimum, j’espère avoir éveillé un certain intérêt pour l’idée de la recherche et du lien intégrés, et peut-être que quelque chose se concrétisera autour de cela à l’avenir. :folded_hands:

1 « J'aime »

Je vois que [[ la recherche magique est réalisable dans un composant de thème aujourd’hui.

La seule réserve est que la complétion supprimerait [[ et le remplacerait par un lien ; je ne vois pas comment cela pourrait fonctionner autrement. Cela rend ]] un peu inutile.

Gardez à l’esprit que maintenir l’auto-complétion ouverte au-delà d’une limite d’espace peut être quelque peu déroutant.

2 « J'aime »

C’est bon à savoir ! En tant que non-programmeur, je ne sais pas vraiment à quel point les choses sont possibles dans les composants de thème (beaucoup, apparemment, ce qui est l’une des nombreuses raisons pour lesquelles j’adore Discourse). C’est donc plutôt cool.

Il est vrai que dans d’autres logiciels, les [[ sont conservés et conservent une certaine valeur même après l’ajout du lien. Ou plutôt, je devrais dire que la recherche [[ ne propose pas automatiquement un lien traditionnel, mais une référence interne spécialisée. Comme plusieurs applications prennent en charge ce format de référence, il est portable dans une variante de Markdown, ce qui est plutôt pratique.

Mais bon, dans le cas de Discourse, [[ n’est qu’un raccourci en ligne familier, qui a la chance de ne pas être déclenché accidentellement. Je serais satisfait par toute autre méthode basée sur le texte pour invoquer une recherche en ligne répondant à des critères similaires, mais malgré les différences de fonctionnement entre Discourse et, par exemple, Roam, je vois tout de même un intérêt à ce que la syntaxe reste la même. Comme je l’ai dit, c’est en quelque sorte un standard de fait en pleine évolution. :thinking:

Une autre chose qui me vient à l’esprit, c’est que Discourse déjà possède son propre équivalent de liens internes qui sont rendus de manière spéciale : c’est ainsi que fonctionnent les citations ! Ainsi, “post:10, topic:200454” renverra bien sûr à votre réponse ici. Puisque cette fonction de lien est spécifiquement destinée aux sujets internes, elle pourrait simplement l’utiliser et l’afficher automatiquement comme un lien vers le sujet au moment du rendu. Je ne sais pas vraiment si cela correspond davantage ou moins à la façon dont Discourse fonctionne… :grinning_face_with_smiling_eyes:

D’un côté, il existe déjà cette méthode de lien ; il ne s’agirait que d’une autre façon d’invoquer la recherche et la sélection de liens, très similaire aux recherches @ et # existantes comme je l’ai mentionné. De l’autre, cela s’écarte du comportement de lien existant invoqué par Ctrl+K, la barre d’outils et d’autres raccourcis. Je pense cependant que le type de lien “post:10” est plus proche du concept de lien [[ tel qu’utilisé dans d’autres applications, donc je pencherais légèrement dans cette direction… si j’avais un poids dans la décision. :wink: Je sais bien sûr que cela relève davantage du domaine des composants de thème, alors peut-être que j’en ai ! Peut-être pouvez-vous simplement donner votre avis sur la possibilité de réaliser un lien de style “post:10” à partir d’une recherche contextuelle dans un composant de thème ?

Je viens d’essayer Roam pour le contexte.

@codinghorror a mentionné à plusieurs reprises par le passé à quel point une recherche en ligne peut être inefficace lorsque vous utilisez l’éditeur, bien que je suppose que, dans le contexte de la documentation et de catégories spécifiques où le contenu est plus restreint, cela puisse être utile.

Nous avons eu des discussions par le passé sur l’introduction d’une syntaxe de type #784, ce qui ressemble beaucoup à cette discussion.

Voici comment Roam fonctionne :

  1. Vous tapez [[
  2. Il ajoute automatiquement ]] et place le curseur à l’intérieur.
  3. Pendant que vous tapez à l’intérieur de [[ ]], il effectue une recherche avec auto-complétion. Par exemple :

  1. Lorsque vous choisissez finalement le lien, il utilise le titre complet, par exemple : [[13 août 2021]]

  2. Il gère automatiquement les renommages du document d’origine en mettant à jour le balisage dans les documents qui y font référence.

Tout comportement similaire nécessiterait un plugin assez étendu pour Discourse, s’interfaçant avec des endroits où les sujets sont renommés, le moteur Markdown, et plus encore. Je classerais cela dans la catégorie des travaux complexes de plusieurs semaines.

Actuellement, nous avons :

4 « J'aime »

Pour une implémentation intéressante à noter, je vous recommande de consulter https://obsidian.md. Ils utilisent cette syntaxe dans les fichiers Markdown et il semble qu’elle soit similaire à la spécification décrite par @sam.

1 « J'aime »

OK, donc c’est là que mon utilisation de Roam comme exemple commence à devenir problématique si on le prend trop à la lettre. :grinning_face_with_smiling_eyes: En fait, j’ai arrêté d’utiliser Roam il y a déjà pas mal de temps, en partie parce que sa recherche en ligne est complètement terrible. Obsidian est un meilleur exemple et c’est ce que j’utilise à temps plein maintenant, mais il nécessite un téléchargement pour l’essayer, tandis que Roam (ou Logseq) ne le font pas.

Avant d’aller plus loin, merci @sam d’avoir tant interagi avec cette idée, dont je réalise qu’elle peut sembler un peu tirée par les cheveux. Et surtout, merci de m’avoir donné une estimation approximative du travail que cela pourrait prendre, du moins selon la manière dont vous l’avez décrite.

Cela dit, je tiens à souligner que ma suggestion est inspirée par Roam et des applications similaires qui utilisent cette syntaxe, mais je ne suis pas intéressé par une tentative de reproduire intégralement tout son fonctionnement.

  • Il n’est pas nécessaire d’automatiser la complétion des crochets, car ceux-ci ne seront pas conservés dans le résultat en markdown (Roam les conserve, tout comme Obsidian).
  • La recherche Discourse, illustrée par la recherche de liens via Ctrl-K ou Ctrl-Alt-F, est meilleure que celle de Roam et, si elle était mise en œuvre en ligne, permettrait probablement de trouver un sujet d’intérêt en un temps raisonnable (c’est-à-dire que si vous pensez que la recherche est utile du tout, elle répondrait déjà au besoin décrit ici).
  • Le lien utiliserait le titre complet, exactement comme si vous aviez copié/collé un lien vers un sujet Discourse dans ce même forum, dans un message.
  • Le renommage serait géré comme Discourse le fait déjà pour les liens internes.

Donc, pour résumer, Roam n’est qu’un exemple pour démontrer le concept et une partie de l’expérience utilisateur. Ce que je propose vraiment, c’est :

  • Un ensemble de caractères peu courants mais rapides à taper, capables de déclencher une recherche de sujet en ligne.
  • Une recherche de sujet en ligne avec Entrée pour sélectionner automatiquement le premier résultat.
  • Une gestion des liens Discourse standard dans tous les autres aspects.
  • Une mise en œuvre d’une manière qui soit le plus possible en accord avec l’approche de Discourse.

Le reste de ce que j’ai dit n’est que des réflexions sur ce qui pourrait avoir le plus de sens ou sur les approches possibles pour résoudre le problème.

Donc, avec tout cela en tête, est-ce que cela change l’estimation du travail nécessaire ? Si non, qu’est-ce exactement dans cette demande de fonctionnalité qui la rend beaucoup plus compliquée que, par exemple, Ctrl-Alt-F + A ? Je pose la question car cela pourrait m’aider à comprendre si je peux réduire la portée de la demande pour rendre les coûts raisonnables, ou si ce n’est tout simplement pas la peine de perdre du temps.

Merci encore !

4 « J'aime »

Pour moi, moins Discourse est compatible avec le Markdown standard, plus certaines autres tâches deviennent difficiles, comme déplacer du contenu entre Discourse et d’autres outils utilisant le Markdown. (Mes sites et ma documentation utilisent généralement le Markdown ou MDX.)

Si une fonctionnalité de ce type devait être ajoutée, une idée alternative pour sa mise en œuvre consisterait à utiliser un système similaire à celui de Confluence ou de Notion, où le caractère / (barre oblique) ouvre un menu.

Voici Confluence :

Voici Notion :

Si une fonctionnalité similaire était intégrée à Discourse, une barre oblique pourrait ouvrir un menu incluant « Lien » comme option. Si « Lien » est sélectionné, l’utilisateur pourrait rechercher d’autres publications et un lien Markdown standard serait inséré dans l’éditeur.

Je ne demande pas l’ajout de cette fonctionnalité, mais je propose simplement une idée alternative de mise en œuvre qui éviterait que le contenu raw ne s’éloigne davantage du Markdown standard. :slight_smile:

3 « J'aime »

Si vous maintenez les choses dans les structures existantes, un composant de thème peut très bien fonctionner et la quantité de travail n’est pas énorme. Le [[ est en fait pratique d’un point de vue de l’implémentation car il vous offre une bonne référence pour savoir où arrêter la complétion automatique.

Un exemple complet de flux de travail pourrait être :

  1. L’utilisateur tape : [[
  2. Le compositeur complète avec ]], le curseur se trouve entre les crochets.
  3. L’utilisateur tape un terme de recherche, par exemple : [[sujet en ligne]]
  4. Pendant que l’utilisateur tape, une recherche est effectuée et les résultats sont affichés dans une complétion automatique similaire aux @mentions.
  5. Utilisez les flèches haut/bas ou Entrée pour sélectionner.
  6. Une fois sélectionné, [[sujet en ligne]] est remplacé par https://meta.discourse.org/t/in-line-topic-search-and-linking-e-g-roam-like-bracket-links/200454.
  7. Si l’utilisateur déplace simplement le curseur au-delà de ]], la complétion automatique se ferme et [[sujet en ligne]] reste tel quel dans le Markdown.

Dans l’ensemble, créer quelque chose comme cela est tout à fait réalisable dans un composant de thème, ne modifie rien côté serveur et serait assez simple à mettre en œuvre. Je dirais qu’un expert pourrait réaliser quelque chose en un jour ou deux, tandis qu’un développeur intermédiaire prendrait probablement une semaine environ.

5 « J'aime »

Oui, les menus activés par la barre oblique sont sans doute une approche intéressante et cool que j’apprécie et que j’utilise dans de nombreuses applications. Je pense que cela ne m’est pas venu à l’esprit comme la méthode à adopter pour réaliser ce que je souhaitais dans ce cas précis, car cette approche implique un ensemble complet de fonctionnalités à invoquer. Autrement dit, je pense qu’il serait étrange ou inattendu, pour les habitués des menus à barre oblique, de n’invoquer que la recherche de liens. Et bien que disposer de nombreuses autres fonctions dans un menu / serait certainement quelque chose que je soutiendrais, cela semble être une demande de fonctionnalité nettement plus importante à mes yeux.

Fantastique, merci d’avoir réfléchi à tout cela et de m’avoir donné une idée de la complexité et du temps de développement ! C’est extrêmement utile. Je devrai réfléchir à la possibilité de financer cela moi-même, car j’ai d’autres demandes peut-être plus importantes que je dois probablement financer pour le développement. Et maintenant que j’en sais plus sur les raccourcis clavier, celui-ci relève davantage d’une commodité que d’une nécessité de toute façon.

2 « J'aime »

Ce serait encore plus intéressant si la création d’un lien nommé lors de l’ajout du lien via a au texte sélectionné était prise en charge. J’aimerais que cette action aboutisse à [texte sélectionné](lien).

Malheureusement, il semble qu’elle ne s’ajoute pas au tampon d’annulation.

2 « J'aime »

D’autres bons exemples de flux de saisie (fonctionnement) avec / et [[ ]] dont on peut s’inspirer sont donnés par

et

3 « J'aime »

Ce système de gestion des connaissances personnelles + concept de forum est vraiment avant-gardiste et potentiellement très puissant. Ce n’est pas « nouveau » (voir par exemple le « Bliki », datant de 2003) mais cela n’a pas à l’être. Le contexte est nouveau, et donc l’idée l’est aussi. Le marché des PKM connaît une croissance très rapide car tout le monde souhaite quelque chose de similaire à ce que vous décrivez, mais cela n’existe pas. Cela dit, je ne pense pas que les wikilinks seraient la bonne solution ; les fonctionnalités de « lien vers la mise en évidence » intégrées à Discourse (en amélioration/variante de la fonctionnalité actuelle de citation) le seraient. Le bouton « Partager » qui apparaît lorsque vous mettez du texte en surbrillance dans un message devrait fournir une URL ainsi qu’une option pour créer un nouveau sujet dans le forum en utilisant la citation (cette dernière fonctionnalité est cachée à trois clics et ne fonctionne pas tout à fait correctement). Mais je peux voir comment il pourrait être utile de créer des wikilinks vers des sujets qui n’existent pas encore, qui deviendraient alors des articles wiki une fois que quelqu’un cliquerait dessus et les créerait.

Je pense que votre Garden est une formidable preuve de concept, et largement limitée par le fait d’avoir été bricolée à partir de Discourse (pensez-vous qu’elle fonctionnerait mieux en tant que wiki, zettelkasten ou instance Circle/Notion ?). Un PKM partagé peut facilement s’effondrer si la qualité des publications n’est pas strictement contrôlée : le contenu profond mais inutile peut s’enraciner sans moyen de discerner la qualité du contenu avant de cliquer. Les forums gèrent la production de connaissances collaboratives ouvertes beaucoup mieux que les PKM conventionnels. Voici un exemple intermédiaire intéressant : LessWrong dispose d’un système de « blog communautaire », qui est en fait un fork de Reddit, et cela fonctionne brillamment pour leurs objectifs. Cela leur permet de supprimer le défi qui consiste à exiger que tous les contributeurs soient bons dans ce qu’ils font dès le départ ; les contributions des utilisateurs (publications et collections de publications de type playlist) ne sont pas canoniques (contrairement au fait qu’il n’y ait généralement qu’un seul article par sujet sur un wiki).

3 « J'aime »

Certaines choses seraient meilleures, mais d’autres nettement pires. Je suis certainement limité par Discourse de certaines manières importantes pour mes objectifs, mais je pense que l’une des principales est simplement la navigation, ce qui semble semi-facile à résoudre si la volonté et donc les ressources de développement sont là. J’ai une idée que je proposerai (avec un financement) bientôt et qui, je l’espère, aidera.

Je pense également qu’il est utile de réfléchir à l’idée d’étendre le concept de Modérateur dans des contextes de génération de connaissances particuliers pour en faire quelque chose de plus proche d’un « Conservateur ». La génération de connaissances en solo combine les rôles/activités de générateur et de conservateur. Mais la génération de connaissances collective nécessite probablement - ou bénéficierait au moins considérablement de - personnes de confiance dont le rôle ou une partie de leur objectif est de citer, promouvoir, organiser, polir et autrement mettre en avant le contenu, les idées, etc. que d’autres génèrent, et de les rendre plus accessibles à ceux qui pourraient en bénéficier. En théorie, la fonctionnalité wiki de Discourse pourrait faire partie de la solution ici, mais elle nécessiterait quelques ajustements.

Il y a aussi beaucoup de choses intéressantes à considérer en termes de génération de connaissances collaborative, de « jardinage numérique », etc. L’objectif est-il de parvenir à des documents singuliers qui représentent une perspective et une compréhension collectives ? Ou de représenter plusieurs perspectives simultanément ? Ou une combinaison des deux. Je peux voir de nombreuses approches possibles pour traiter ces questions et d’autres.

En fin de compte, le défi est que CDCK n’est probablement pas très intéressé par ces utilisations de Discourse (ce que je peux comprendre, leur utilité et donc leur potentiel de revenus sont beaucoup plus naissants et incertains à ce stade). Et pendant ce temps, peu - sinon aucune - autre plateforme qui se concentre sur la génération de connaissances, par exemple Wikipedia/MediaWiki, aborde suffisamment bien les aspects conversationnels et de discussion, et surtout l’interaction entre les deux. Dans un monde idéal, une discussion de haute qualité sur de longues périodes pourrait ajouter progressivement à un résultat distillé de connaissances, d’idées, de perspectives, facilement et fluidement, en maintenant l’attribution tout en permettant une sortie « document »/artefact bien formatée et cohérente qui serait agréable à lire. Wikipedia est à nouveau un bon exemple du modèle actuel qui fonctionne, mais il est très imparfait et de nouveaux outils et méthodes sont nécessaires pour aller au-delà de la simple documentation des connaissances pour réellement générer des idées, explorer de nouvelles idées, etc.

Discourse peut être utilisé pour ces choses maintenant, d’une manière plus facile que d’autres. Mais cela peut être fait, il a la plupart de ce qui est nécessaire…

4 « J'aime »