Préférences d'interface utilisateur : inclure un paramètre pour désactiver les rappels IA

J’apprécierais vraiment que l’interface utilisateur de Discourse n’essaie pas de me vendre de l’IA. Je n’achète pas, ni maintenant, ni jamais. Pourrait-il y avoir une préférence qui désactive les suggestions de résumer chaque publication avec l’IA ?

Je remarque que cela ne se produit pas sur ce site. Je vois d’après d’autres publications que le résumé par IA est un module complémentaire. Cela me convient si TC39 (l’organisation des normes JS) dispose de ce module complémentaire, mais mes préférences personnelles sont différentes des leurs et mon désir de voir leurs valeurs m’être imposées est de 0.

Bienvenue sur Meta :waving_hand:

Pouvez-vous clarifier de quelles incitations vous parlez ? Actuellement, je ne suis pas sûr si vous parlez d’une fonctionnalité du plugin officiel Discourse ai, ou s’il s’agit d’une fonctionnalité personnalisée sur un autre forum Discourse que vous utilisez.

Je connais le bouton pour résumer les sujets, mais je ne suis pas au courant d’une fonctionnalité qui affiche un bouton de résumé sur chaque publication.

1 « J'aime »

Oui, ce sont ceux dont je parle. Je suppose qu’ils existent aussi sur ce site.

Je suppose que vous pourriez utiliser du CSS avec un plugin de navigateur comme Stylus pour masquer le bouton pour vous-même. J’utilise cela pour supprimer une autre partie de la carte thématique sur ce site.

Je suis ingénieur frontend de profession, donc cette pensée m’est venue à l’esprit. Laissons cela de côté un instant et disons que je voulais coder une Pull Request (PR) pour Discourse qui créerait un nouveau paramètre pour désactiver cette fonctionnalité, une PR de haute qualité à cet effet serait-elle acceptée ?

Je ne peux pas répondre en leur nom, mais en général, ils ont tendance à réfléchir plus de deux fois avant d’ajouter de nouveaux paramètres de personnalisation pour éviter une complexité inutile, et privilégient les demandes de fonctionnalités qui prennent de l’ampleur.

1 « J'aime »

Ce n’est pas exactement une demande aléatoire. Je sais que je suis très loin d’être la seule personne à être opposée à l’IA pour des raisons éthiques. Je suis également profondément aigri à propos de cette technologie compte tenu de ses effets corrosifs sur la collaboration et la compétence. Presque tous les outils qui ont choisi d’intégrer des fonctionnalités d’IA ont également fait face à une demande importante pour pouvoir toutes les désactiver : Firefox, VSCode, Notion, etc.

1 « J'aime »

C’est assez important.

Nous apprécions beaucoup recevoir ces PR de haute qualité, mais chaque paramètre entraîne des frais généraux d’une manière ou d’une autre, nous essayons donc très fort d’être critiques quant à ce que nous ajoutons en tant que tel.

Une autre solution serait de soulever la question sur le forum que vous utilisez vous-même… peut-être pouvez-vous les convaincre de le désactiver complètement.

Dans tous les cas, avant d’investir votre propre temps et vos efforts dans la création de cette PR, une bonne chose à faire serait de faire une demande de Feature et de voir si votre idée reçoit un quelconque soutien.

Cependant, si vous pouvez facilement le masquer via CSS comme suggéré ici, je suis curieux de savoir pourquoi vous êtes si déterminé à en faire un paramètre ? Est-ce simplement motivé par l’idéologie ?

1 « J'aime »

notez que les administrateurs peuvent déjà désactiver complètement l’IA avec un seul interrupteur
en tant que préférence utilisateur, la portée impliquerait principalement de masquer facultativement les boutons… les individus ne pourraient pas désactiver entièrement les fonctionnalités d’IA utilisées par un administrateur, comme la détection de spam

2 « J'aime »

Oui, je me doutais qu’un simple réglage dans l’interface utilisateur ne ferait guère plus que basculer le bouton. Mais c’est vraiment ce que je veux. Comme je n’utiliserai jamais ce bouton, il n’améliore pas le produit pour moi, et donc je préférerais ne pas le voir.

1 « J'aime »

Je voulais désactiver toutes les intégrations d’IA sur mon site, et je suis vraiment ravi que cela ne nécessite qu’un seul paramètre. Une réponse à la question de l’OP pourrait être l’équivalent de discourse_ai_enabled, mais appliqué au niveau de chaque utilisateur. Ainsi, l’IA ne serait pas simplement activée ou désactivée pour l’ensemble du site. Même les fonctionnalités d’IA activées au niveau du site pourraient être supprimées au niveau de chaque utilisateur. La logique de discourse_ai_enabled serait alors : site-wide == true et per-user == true.

Bien qu’il soit généralement vrai que l’équipe réfléchisse à l’ajout de nouveaux paramètres de personnalisation pour éviter une complexité inutile, l’IA est la fonctionnalité disposant du plus grand nombre de paramètres configurables. En très peu de temps depuis son apparition, elle semble être devenue la fonctionnalité la plus personnalisable de Discourse.[1]

Voici une analyse rapide et approximative. Je suis relativement nouveau ici, je montre donc mes calculs au cas où j’aurais fait une erreur.

su discourse -c 'bundle exec rails runner "SiteSetting.defaults.all.keys.sort.each { |k| puts k }"' > keys.txt
wc -l keys.txt
1663 keys.txt
cut -d _ -f 1 keys.txt | sort | uniq -c | sort -rn > counts.txt

Si c’est la bonne méthode pour les compter, il existe 1663 paramètres de site possibles. Parmi ceux-ci, 104 commencent par ai_ et 3 paramètres d’IA ne le font pas (composer_ai_helper_allowed_groups, discourse_ai_enabled et post_ai_helper_allowed_groups). Ainsi, selon mon estimation, l’IA constitue le plus grand groupe de paramètres personnalisés de loin (107 sur 1663, soit 6,4 % de tous les paramètres de site). Voici le top 10 :

  • 107 ai
  • 84 discourse
  • 83 chat
  • 71 max
  • 65 enable
  • 48 default
  • 30 dfp
  • 28 oauth2
  • 28 amazon
  • 28 allow

D’un côté, la suppression des fonctionnalités d’IA au niveau de chaque utilisateur n’est qu’une option supplémentaire parmi 1663. De l’autre, il pourrait être difficile de vérifier ce paramètre au niveau de chaque utilisateur alors que de nombreux chemins de code le vérifient au niveau du site. C’est un compromis sur lequel je ne suis pas qualifié pour émettre des hypothèses.


  1. C’est également une fonctionnalité assez bien définie et autonome, et relativement récente, ce qui rend son nommage cohérent avec le préfixe ai_ et facilite le comptage de ses paramètres par rapport à d’autres composants. C’est pourquoi je qualifie cette analyse de rapide et approximative. ↩︎