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 