Je me retrouve souvent à vouloir utiliser les automatisations, mais à me sentir limité par leur fonctionnement actuel. Je trouve souvent qu’un script a quelque chose dont j’ai besoin, alors que j’ai besoin que cette partie fonctionne dans le contexte d’un autre script.
Il semble que cela soit largement lié à la façon dont les automatisations fonctionnent et sont configurées actuellement. J’aimerais voir les choses divisées en Déclencheurs et Actions.
Exemples de déclencheurs :
Lorsqu’un sujet est créé/mis à jour
Lorsqu’un message est créé/mis à jour
Lorsqu’un paramètre du site change
Lorsqu’un sujet est fermé
Lorsqu’un utilisateur obtient un badge
etc.
Exemples d’actions :
Créer un sujet de bannière
Fermer un sujet
Répondre à un sujet
Créer un sujet
Étiqueter un sujet
Exécuter un appel LLM
Envoyer un message Slack
etc.
Cette configuration permettrait plusieurs choses :
Attribuer plusieurs actions suite à un déclencheur (par exemple, lorsqu’un sujet est créé > Exécuter un appel LLM > Étiqueter le message > Répondre au sujet)
Permettre d’utiliser dynamiquement les données de charge utile du déclencheur (et les données ultérieures rendues disponibles par les actions - par exemple, la réponse de l’appel LLM) dans les actions.
En fin de compte, je pense que l’automatisation a beaucoup de potentiel, mais chaque script est isolé d’une manière qui rend très difficile sa personnalisation aux besoins individuels. Chacun suppose actuellement que les actions disponibles conviendront à tout le monde.
J’aime beaucoup cette proposition ! Elle semble résoudre la plupart (sinon tous) des points de douleur actuels des automatisations.
Elle semble également beaucoup plus évolutive pour les nouveaux Déclencheurs (Triggers) et Actions. J’imagine que cela ouvrirait la voie à l’ajout facile de déclencheurs supplémentaires - comme theme_created ou theme_updated - sans avoir à se soucier de la manière dont ils interagissent avec les scripts préexistants. Les nouveaux déclencheurs gagneraient instantanément accès à toutes les actions existantes (notifications Slack, messages privés, appels LLM, etc.). Il en va de même pour la création d’actions supplémentaires comme assign_badge, add_to_group, add_to_logs_and_screening, et ainsi de suite.
Ohhh, et les fonctions « Exécution à blanc » (Dry run) et « Journaux d’exécution » (Execution logs) sont également parfaites - avoir ce niveau d’observabilité sur la façon dont les choses s’exécutent réellement est un sauveur absolu.
Juste un petit mot : en plus du déclencheur/filtre/action, pouvoir ajouter des délais serait précieux.
(Exemple : intégration/incitations, envoyer un message une semaine après avoir rejoint la communauté, puis deux mois plus tard, ou si un membre n’a pas publié ou lu, etc., faire quelque chose X jours après avoir rejoint… ce n’est certainement pas quelque chose que n’importe quelle communauté utiliserait, mais pour le type de communauté de support actif comme la nôtre, ce serait le cas !)
Bien que cela soit encore au stade conceptuel, je continuerai à y réfléchir
Concernant les conditions, je me demandais quelle flexibilité pourrait réellement être intégrée. Ce serait formidable de mettre en œuvre quelque chose comme la capture d’écran, où l’utilisateur a un contrôle total sur la manière dont les critères sont construits. Permettre aux utilisateurs de sélectionner des données dans le trigger_context, de définir comment elles sont évaluées et de définir ce à quoi elles sont évaluées - tout en leur permettant de choisir entre la logique ET / OU.
Cela débloquerait des scénarios plus complexes, tout en restant facile et intuitif à comprendre, comme :
si {{category}} est l'un de {{valeur sélectionnée par l'utilisateur}}ET
si {{tag}} n'est pas {{valeur sélectionnée par l'utilisateur}}
La capture d’écran inclut également ce qu’il faut faire après la vérification de la condition, mais cela ne s’appliquerait probablement qu’aux pipelines ramifiés - pour un pipeline linéaire, qui couvre la plupart des cas, alors il se terminerait probablement simplement
