La force de Gladys, c’est vous : comment on s’organise pour grandir 🙂

[pierre-gilles]

Bonjour à tous,

Le forum n’a jamais été aussi actif : nouveaux membres, nouvelles intégrations publiées chaque jour, discussions passionnantes. Merci à vous, c’est grâce à vous que Gladys avance aussi vite !

Avec cette belle croissance, il y a un sujet dont je veux vous parler franchement : les tags

Je suis de plus en plus tagué un peu partout sur le forum, par les nouveaux comme par les anciens, souvent pour des questions qui n’ont pas besoin de moi. Je comprends complètement le réflexe, mais il a l’effet inverse de celui recherché : quand je reçois des dizaines de mentions, les messages qui ont vraiment besoin de moi se retrouvent noyés dans la masse.

Résultat, je réponds moins vite à tout le monde, et parfois plus du tout.

Mon objectif : me rendre moins essentiel

Toute ma mission de ces 6 derniers mois a été de me rendre moins indispensable au projet. Ce n’est pas un désengagement, c’est tout l’inverse : un projet qui dépend d’une seule personne est un projet fragile, et je veux que Gladys soit solide pour les années à venir.

C’est d’ailleurs dans cet esprit que les intégrations externes ont totalement libéré le projet en quelques mois : chacun est libre d’ajouter des intégrations, des widgets, des actions et des déclencheurs de scènes.

C’est aussi une nécessité très concrète : je serai absent pendant mon congé paternité , et le projet doit apprendre à continuer à vivre sans moi. Et la bonne nouvelle, c’est qu’il en est déjà capable ! Je vois tous les jours des questions résolues par la communauté en quelques heures, sans que j’aie besoin d’intervenir. C’est exactement ce que je rêvais de voir.

Ce que je fais du temps libéré

Chaque mention en moins, c’est du temps en plus pour faire avancer Gladys.

Concrètement, en ce moment :

• Les intégrations externes fournisseur IA et TTS
• nombreux correctifs suite à la vague de nouveaux utilisateurs
• Installation et expédition des derniers kits de démarrage avant que je ne ferme boutique pour mon congé paternité.
• Tout ce que j’avais listé ici : Gladys d'ici fin 2026 : une grande nouvelle et un plan ambitieux 🚀 - #62 par pierre-gilles
• et un objectif ambitieux : que tout soit en place pour qu’on ait 1 000 intégrations externes d’ici fin 2026.

Je continue évidemment de lire le forum, je ne disparais pas, je me concentre là où j’ai le plus d’impact

Ce qui a vraiment besoin de moi

Il n’y a que deux types de sujets pour lesquels me taguer est utile :

• La réflexion long terme sur la philosophie du projet : la direction de Gladys, les grands choix d’architecture et de vision.
• Un vrai blocage lié à un problème de droits : si vous êtes bloqué parce que personne n’a les accès nécessaires, je débloque la situation en donnant les droits à d’autres personnes. Pour ce type de blocage uniquement, @cicoub13 et @bertrandda ont souvent les mêmes droits que moi et peuvent vous débloquer tout aussi bien

Pour tout le reste

Discutez avec la communauté, faites vos propres recherches sur le forum et dans la documentation, et utilisez l’IA. Je vais être très honnête : Claude Code est plus intelligent que moi, et il est meilleur que moi pour répondre à vos questions sur Gladys

Il a accès à tout le code, il ne dort jamais et il répond en quelques secondes.

Pour ceux qui n’ont pas les moyens de payer Claude Code, demandez à ceux qui l’ont

En revanche, n’utilisez surtout pas d’IA gratuite et n’ayant pas accès au code de Gladys, leur utilisation est contre productive : sans le code sous les yeux, elles devinent : elles inventent des commandes et des options qui n’existent pas, et vous affirment avec beaucoup d’aplomb qu’elles ont raison. Vous risquez de perdre plus de temps qu’en posant directement la question au forum.

Vous avez trouvé un bug ?

1. Parlez-en sur le forum, la communauté vous aidera à vérifier.
2. Une fois le bug confirmé, créez une issue GitHub : Issues · GladysAssistant/Gladys · GitHub

C’est l’étape la plus importante. Un bug sans issue GitHub est un bug perdu, qui ne sera jamais corrigé. À l’inverse, un bug avec une issue est souvent corrigé très rapidement

Un doute sur le fait que ce soit vraiment un bug ? Demandez à Claude Code d’analyser le code de Gladys, c’est le moyen le plus rapide d’en avoir le cœur net.

Vous avez une idée de fonctionnalité ?

Créez un sujet dans la catégorie Demande de fonctionnalités. Une idée lancée au détour d’une discussion est vite oubliée, alors qu’un sujet dédié peut être voté, discuté et suivi jusqu’à sa sortie.

Merci

Ce qui rend Gladys unique, c’est cette communauté bienveillante et passionnée. Chaque réponse que vous donnez à un nouveau, chaque issue bien remplie, chaque idée bien argumentée fait grandir le projet ! On construit ça ensemble, et je suis vraiment fier de ce que cette communauté est devenue.

Vivement la suite !

[stefanbauer]

Ce qui me manque vraiment, ou que je ne trouve tout simplement pas, c’est comment se déroule le processus ultérieur. Maintenant, il y a plus de 50 PR ouvertes. Qui les examine ? Qui décide ce qui est fusionné ? Qui décide quand c’est fusionné ? Qui a les droits à ce sujet ? C’est pour moi malheureusement encore une grande boîte noire, car cette procédure claire et espérons-le structurée n’est documentée nulle part. À moins que je sois vraiment aveugle et ne la trouve pas. Dans ce cas, je serais ravi de recevoir l’information ou un lien.

[pierre-gilles]

Bonjour @stefanbauer,

Merci d’avoir soulevé ce point, c’est une question très juste, et vous avez raison, ce n’est pas assez visible aujourd’hui.

Une partie de la réponse est expliquée ici : MAINTAINERS.md. Elle explique qui peut examiner et fusionner quoi, et comment une version est créée. En bref : master est protégé. Chaque PR a besoin d’une CI verte (tests, lint, 100% de couverture de patch) et passe par les examens automatisés (Cursor, CodeRabbit). Ensuite, elle a besoin de l’approbation d’un examinateur humain qui est autorisé à approuver les fichiers qu’elle touche, et elle est fusionnée via la file d’attente de fusion.

Aujourd’hui, trois personnes peuvent examiner et fusionner les PR sur Gladys : moi, @cicoub13 et @bertrandda.

Pour être honnête avec vous : Gladys grandit très vite en ce moment. Nous n’avons jamais eu autant de contributeurs, d’intégrations et de PR en même temps. Nous tâtonnons encore, et cela se voit dans le processus. Nous allons l’améliorer.

Il y a aussi une échéance personnelle de mon côté : je vais bientôt devenir père, et je serai absent pendant environ 2 mois de congé de paternité (plus d’informations ici). Je suis généralement très rapide pour examiner les PR, mais en ce moment, je me concentre sur quelques sujets de très haute priorité avant de partir : ceux qui libèrent Gladys de sa dépendance envers moi (intégrations externes, et l’organisation décrite dans MAINTAINERS.md). C’est pourquoi certaines PR attendent plus longtemps que d’habitude.

En attendant, @cicoub13 et @bertrandda peuvent examiner les PR pour les corrections de bugs et les modifications des intégrations internes, donc celles-ci n’ont pas besoin d’attendre.

Je suis très motivé pour faire évoluer Gladys vers de bonnes pratiques de gestion de projet open source : une documentation plus claire du processus, plus de personnes avec des droits d’examen, un chemin plus prévisible de « PR ouverte » à « PR fusionnée ». Des retours comme le vôtre aident beaucoup. Si vous pensez que quelque chose manque ou n’est pas clair dans MAINTAINERS.md, faites-le nous savoir !

Merci encore pour votre implication

[stefanbauer]

@pierre-gilles Merci pour ta réponse éclairante. S’il te plaît, ne prends pas cela comme une critique, mais simplement comme un intérêt sincère à comprendre les choses et éventuellement à les améliorer. Mais je pense que tu l’as compris ainsi

Je vais, quand j’aurai le temps, tout revoir et voir où je pourrais éventuellement soutenir @cicoub13 et @bertrandda. Je suis d’accord avec toi… on voit bien que beaucoup de choses se passent en même temps et qu’on n’arrive pas vraiment à suivre. C’est pourquoi j’offre volontiers mon aide chaque fois que c’est possible.

Concernant ton congé parental : la famille passe toujours en premier. J’ai malheureusement dû l’apprendre à mes dépens. C’est pourquoi je ne veux pas te retenir plus longtemps. Fais ce qui est nécessaire et sinon, profite du temps à venir, car il ne reviendra pas.

Si tu as besoin d’aide ou si on peut t’aider d’une autre manière, n’hésite pas à nous le faire savoir. Bonne chance!

[pierre-gilles]

Merci beaucoup @stefanbauer, et ne vous inquiétez pas du tout, je ne l’ai pas pris comme une critique. Des questions comme les vôtres sont exactement ce qui nous aide à nous améliorer, alors n’hésitez pas à continuer

Et merci pour vos gentils mots sur la famille

Une chose importante à garder à l’esprit sur la direction que prend Gladys : la plupart des nouveaux développements se font désormais via des intégrations externes. N’importe qui peut construire et publier une intégration, un widget, une action de scène ou un déclencheur, sans attendre qu’une PR soit revue et fusionnée dans le cœur. Le cœur vise à être une base stable : corrections, fiabilité et les contrats sur lesquels s’appuient les intégrations externes, plutôt qu’un endroit où chaque nouvelle fonctionnalité doit atterrir. Donc si vous avez une idée pour une nouvelle fonctionnalité ou intégration, une intégration externe est souvent le moyen le plus rapide de la mettre entre les mains des utilisateurs.

Votre offre d’aide est très bienvenue, et il y a beaucoup que vous pouvez faire dès maintenant, sans aucun droit spécial.

Sur le forum :

• Répondre aux questions des nouveaux arrivants, aider les gens à déboguer leur configuration, et vérifier si un problème signalé est vraiment un bug avant qu’il ne devienne une issue GitHub.
• Aider les gens à transformer leurs idées en demandes de fonctionnalités bien rédigées, ou les orienter vers une intégration externe existante.

C’est tout aussi précieux que le code : chaque question à laquelle la communauté répond est du temps que nous pouvons consacrer à faire avancer Gladys.

Sur GitHub :

• Revoir les PR ouvertes : n’importe qui peut laisser une revue ou des commentaires. Même si cela ne compte pas comme l’approbation finale, un deuxième regard sauve beaucoup de temps à @cicoub13 et @bertrandda. Ils peuvent alors se concentrer sur ce qui a vraiment besoin de leur approbation.
• Tester les PR : vérifier qu’une correction fonctionne vraiment sur votre configuration, et le dire dans la PR, est très précieux, surtout pour les intégrations que nous ne pouvons pas tester nous-mêmes.
• Aider au tri des issues : repérer les doublons, demander les informations manquantes, vérifier si un bug peut être reproduit.

C’est aussi ce que décrit MAINTAINERS.md comme le parcours : les contributeurs actifs rejoignent l’équipe de tri, puis l’équipe centrale une fois qu’ils ont suffisamment revu et été revus. Donc si vous commencez à aider, vous êtes déjà sur ce chemin !

Merci encore pour votre soutien, cela aide vraiment

[Will_71]

Le problème est que tu as toujours géré pratiquement tout seul, alors c’est devenu une habitude de te taguer.
Après, c’est sûr que si tu reçois des tonnes de notifications à la fin, tu ne les regardes pas tous ou pas du tout.
Merci à @cicoub13 et @bertrandda d’avoir accepté de t’épauler dans cette tâche.

[cicoub13]

Sans parler des notifications GitHub