Gladys' strength is you: how we're organizing to grow 🙂

News
1

Hello everyone,

The forum has never been so active: new members, new integrations published every day, passionate discussions. Thank you, it’s thanks to you that Gladys is moving so fast! :tada:

With this beautiful growth, there is a topic I want to talk to you frankly about: tags :sweat_smile:

I am increasingly tagged all over the forum, by newbies and veterans alike, often for questions that don’t need me. I completely understand the reflex, but it has the opposite effect of what is intended: when I receive dozens of mentions, the messages that really need me get lost in the crowd.

As a result, I respond less quickly to everyone, and sometimes not at all.

:seedling: My goal: making myself less essential

My entire mission over the past 6 months has been to make myself less indispensable to the project. This is not a disengagement, it’s quite the opposite: a project that depends on a single person is a fragile project, and I want Gladys to be solid for the years to come.

This is also the spirit in which external integrations have completely freed the project in a few months: everyone is free to add integrations, widgets, actions, and scene triggers.

It’s also a very concrete necessity: I will be absent during my paternity leave :baby:, and the project must learn to continue living without me. And the good news is that it’s already capable of it! I see questions resolved by the community in a few hours every day, without me needing to intervene. This is exactly what I dreamed of seeing. :flexed_biceps:

:hammer: What I do with the freed-up time

Each mention less is more time to move Gladys forward.

Concretely, at the moment:

I obviously continue to read the forum, I’m not disappearing, I’m focusing where I have the most impact :wink:

:bullseye: What really needs me

There are only two types of topics for which tagging me is useful:

  • Long-term reflection on the project’s philosophy: the direction of Gladys, the big architectural and vision choices.
  • A real blockage related to a rights issue: if you are stuck because no one has the necessary access, I unblock the situation by giving rights to other people. For this type of blockage only, @cicoub13 and @bertrandda often have the same rights as me and can unblock you just as well :wink:

:handshake: For everything else

Talk to the community, do your own research on the forum and in the documentation, and use AI. I’ll be very honest: Claude Code is smarter than me, and it’s better than me at answering your questions about Gladys :robot:

It has access to all the code, it never sleeps, and it responds in a few seconds.

For those who can’t afford Claude Code, ask those who have it :wink:

On the other hand, do not use free AI that does not have access to Gladys’s code, their use is counterproductive: without the code in front of them, they guess: they invent commands and options that don’t exist, and they assert with great confidence that they are right. You risk wasting more time than by directly asking the question on the forum.

:bug: Found a bug?

  1. Talk about it on the forum, the community will help you verify.
  2. Once the bug is confirmed, create a GitHub issue: Issues · GladysAssistant/Gladys · GitHub

This is the most important step. A bug without a GitHub issue is a lost bug, which will never be fixed. On the other hand, a bug with an issue is often fixed very quickly :high_voltage:

Not sure if it’s really a bug? Ask Claude Code to analyze Gladys’s code, it’s the fastest way to get to the bottom of it.

:sparkles: Have an idea for a feature?

Create a topic in the Demande de fonctionnalités category. An idea thrown in during a discussion is quickly forgotten, whereas a dedicated topic can be voted on, discussed, and followed until its release.

:blue_heart: Thank you

What makes Gladys unique is this benevolent and passionate community. Every answer you give to a newbie, every well-filled issue, every well-argued idea makes the project grow! We’re building this together, and I’m really proud of what this community has become.

Looking forward to the next steps! :rocket:

3

What I’m actually missing, or perhaps I just can’t find the information, is how the further process works. Now, there are over 50 open PRs. Who reviews them? Who decides what gets merged? Who decides when it gets merged? Who has the rights to do so? For me, this is unfortunately still a big black box, as this clear and hopefully structured procedure is documented nowhere. Unless I’m really blind and just can’t find it. If that’s the case, please send me the info or a link.

4

Hi @stefanbauer,

Thanks for raising this, it’s a very fair question, and you’re right that it’s not visible enough today.

Part of the answer is written down here: MAINTAINERS.md. It explains who can review and merge what, and how a release is made. In short: master is protected. Every PR needs green CI (tests, lint, 100% patch coverage) and goes through the automated reviews (Cursor, CodeRabbit). Then it needs the approval of a human reviewer who is allowed to approve the files it touches, and it is merged through the merge queue.

Today, three people can review and merge PRs on Gladys: me, @cicoub13 and @bertrandda.

To be honest with you: Gladys is growing very fast right now. We’ve never had this many contributors, integrations and PRs at the same time. We’re still feeling our way, and it shows in the process. We’re going to improve it.

There’s also a personal deadline on my side: I’m soon going to be a dad, and I’ll be away for about 2 months of paternity leave (more about it here). I’m usually very quick to review PRs, but right now I’m focusing on a few very high-priority topics before I leave: the ones that free Gladys from depending on me (external integrations, and the organization described in MAINTAINERS.md). That’s why some PRs are waiting longer than usual.

In the meantime, @cicoub13 and @bertrandda can review PRs for bug fixes and changes to internal integrations, so those don’t need to wait for me.

I’m very motivated to move Gladys towards good open-source project management practices: clearer documentation of the process, more people with review rights, a more predictable path from “PR opened” to “PR merged”. Feedback like yours helps a lot. If you think something is missing or unclear in MAINTAINERS.md, please tell us!

Thanks again for your involvement :folded_hands:

5

@pierre-gilles Thanks for your insightful answer. Please don’t take this as criticism, but rather as a genuine interest in understanding things and possibly improving them. But I think you’ve taken it that way too :slight_smile:

When I have time, I’ll go through everything and see where I might be able to support @cicoub13 and @bertrandda as well. I agree with you
 you can tell that a lot is happening at the same time right now and you can’t quite keep up. That’s why I’m also happy to offer my help wherever possible.

Regarding your parental leave: family always comes first. Unfortunately, I had to learn that the hard way. So I don’t want to keep you any longer. Fix what needs to be fixed and otherwise enjoy the coming time, because it won’t come back.

If you need help or if there’s anything else we can support you with, feel free to let us know anytime. All the best! :baby:

6

Thanks a lot @stefanbauer, and no worries at all, I didn’t take it as criticism. Questions like yours are exactly what helps us get better, so please keep them coming :slightly_smiling_face:

And thank you for your kind words about the family :folded_hands:

One important thing to keep in mind about where Gladys is heading: most new development now happens through external integrations. Anyone can build and publish an integration, a widget, a scene action or a trigger, without waiting for a PR to be reviewed and merged in the core. The core aims to be a stable foundation: fixes, reliability and the contracts that external integrations rely on, rather than a place where every new feature has to land. So if you have an idea for a new feature or integration, an external integration is often the fastest way to get it into users’ hands.

Your offer to help is very welcome, and there’s a lot you can do right away, without any special rights.

On the forum:

  • Answering questions from newcomers, helping people debug their setup, and checking whether a reported problem is really a bug before it becomes a GitHub issue.
  • Helping people turn their ideas into well-written feature requests, or pointing them to an existing external integration.

This is just as valuable as code: every question the community answers is time we can spend moving Gladys forward.

On GitHub:

  • Review open PRs: anyone can leave a review or comments. Even if it doesn’t count as the final approval, a second pair of eyes saves a lot of time for @cicoub13 and @bertrandda. They can then focus on what really needs their approval.
  • Test PRs: checking that a fix really works on your setup, and saying so in the PR, is very valuable, especially for integrations we can’t test ourselves.
  • Help triage issues: spotting duplicates, asking for missing info, checking whether a bug can be reproduced.

That’s also how MAINTAINERS.md describes the path: active contributors join the triage team, then the core team once they’ve reviewed and been reviewed enough. So if you start helping, you’re already on that path!

Thanks again for your support, it really helps :folded_hands:

8

The problem is that you’ve always managed everything practically on your own, so it’s become a habit to tag you.
After that, it’s certain that if you receive tons of notifications at the end, you don’t look at all of them or not at all.
Thanks to @cicoub13 and @bertrandda for agreeing to help you with this task.

9

Not to mention the GitHub notifications :sweat_smile:

image
image1206×2622 468 KB