La fuerza de Gladys, sois vosotros: cómo nos organizamos para crecer 🙂

Hola a todos,

El foro nunca ha estado tan activo: nuevos miembros, nuevas integraciones publicadas cada día, discusiones apasionantes. ¡Gracias a todos, es gracias a vosotros que Gladys avanza tan rápido! :tada:

Con este hermoso crecimiento, hay un tema del que quiero hablaros con franqueza: las etiquetas :sweat_smile:

Cada vez me etiquetan más por todas partes en el foro, tanto los nuevos como los antiguos, a menudo por preguntas que no requieren mi intervención. Entiendo completamente el reflejo, pero tiene el efecto contrario al buscado: cuando recibo decenas de menciones, los mensajes que realmente necesitan mi atención se pierden en la masa.

Como resultado, respondo menos rápido a todos, y a veces ya no lo hago.

:seedling: Mi objetivo: volverme menos esencial

Mi misión durante los últimos 6 meses ha sido volverme menos indispensable para el proyecto. No es un desinterés, es todo lo contrario: un proyecto que depende de una sola persona es un proyecto frágil, y quiero que Gladys sea sólido para los años venideros.

De hecho, es en este espíritu que las integraciones externas han liberado completamente el proyecto en unos pocos meses: cada uno es libre de añadir integraciones, widgets, acciones y desencadenadores de escenas.

También es una necesidad muy concreta: estaré ausente durante mi licencia de paternidad :baby:, y el proyecto debe aprender a seguir viviendo sin mí. ¡Y la buena noticia es que ya es capaz de hacerlo! Veo todos los días preguntas resueltas por la comunidad en unas pocas horas, sin que yo tenga que intervenir. ¡Es exactamente lo que soñaba ver! :flexed_biceps:

:hammer: Qué hago con el tiempo liberado

Cada mención menos es tiempo extra para hacer avanzar a Gladys.

Concretamente, en este momento:

  • Las integraciones externas de proveedores de IA y TTS
  • numerosos correctivos tras la ola de nuevos usuarios
  • Instalación y envío de los últimos kits de inicio antes de que cierre mi tienda para mi licencia de paternidad.
  • Todo lo que había listado aquí: Gladys d'ici fin 2026 : une grande nouvelle et un plan ambitieux 🚀 - #62 par pierre-gilles
  • y un objetivo ambicioso: que todo esté en su lugar para tener 1,000 integraciones externas para finales de 2026.

Por supuesto, sigo leyendo el foro, no desaparezco, me concentro donde tengo más impacto :wink:

:bullseye: Qué realmente necesita de mí

Solo hay dos tipos de temas para los cuales etiquetarme es útil:

  • La reflexión a largo plazo sobre la filosofía del proyecto: la dirección de Gladys, las grandes decisiones de arquitectura y visión.
  • Un verdadero bloqueo relacionado con un problema de derechos: si están bloqueados porque nadie tiene los accesos necesarios, desbloqueo la situación dando los derechos a otras personas. Para este tipo de bloqueo únicamente, @cicoub13 y @bertrandda a menudo tienen los mismos derechos que yo y pueden desbloquearlos igual de bien :wink:

:handshake: Para todo lo demás

Habla con la comunidad, haz tus propias investigaciones en el foro y en la documentación, y usa la IA. Voy a ser muy honesto: Claude Code es más inteligente que yo, y es mejor que yo para responder a tus preguntas sobre Gladys :robot:

Tiene acceso a todo el código, nunca duerme y responde en unos pocos segundos.

Para aquellos que no tienen los medios para pagar Claude Code, pídanle a quienes lo tienen :wink:

En cambio, no usen especialmente IA gratuita y que no tenga acceso al código de Gladys, su uso es contraproducente: sin el código a la vista, adivinan: inventan comandos y opciones que no existen, y les afirman con mucha seguridad que tienen razón. Riesgan perder más tiempo que haciendo directamente la pregunta en el foro.

:bug: ¿Encontraste un error?

  1. Habla de ello en el foro, la comunidad te ayudará a verificar.
  2. Una vez confirmado el error, crea un issue en GitHub: Issues · GladysAssistant/Gladys · GitHub

Este es el paso más importante. Un error sin un issue en GitHub es un error perdido, que nunca será corregido. Por el contrario, un error con un issue a menudo se corrige muy rápidamente :high_voltage:

¿Dudas de si realmente es un error? Pide a Claude Code que analice el código de Gladys, es la manera más rápida de estar seguro.

:sparkles: ¿Tienes una idea de funcionalidad?

Crea un tema en la categoría Demande de fonctionnalités. Una idea lanzada al pasar en una discusión se olvida rápidamente, mientras que un tema dedicado puede ser votado, discutido y seguido hasta su lanzamiento.

:blue_heart: Gracias

Lo que hace único a Gladys es esta comunidad bienintencionada y apasionada. Cada respuesta que das a un nuevo miembro, cada issue bien completado, cada idea bien argumentada hace crecer el proyecto. ¡Lo construimos juntos, y estoy realmente orgulloso de lo que esta comunidad se ha convertido!

¡Que venga lo siguiente! :rocket:

Lo que realmente echo de menos, o no encuentro la información, es cómo es el proceso posterior. Bueno, hay más de 50 PRs abiertas. ¿Quién las revisa? ¿Quién decide qué se fusiona? ¿Quién decide cuándo se fusiona? ¿Quién tiene los derechos para hacerlo? Para mí sigue siendo una gran caja negra, ya que este procedimiento claro y espero que estructurado no está documentado en ningún sitio. A menos que realmente sea ciego y no lo encuentre. Si es así, me encantaría que me enviaran la información o un enlace.

Hola @stefanbauer,

Gracias por plantear esto, es una pregunta muy justa y tienes razón en que no es lo suficientemente visible hoy.

Parte de la respuesta está escrita aquí: MAINTAINERS.md. Explica quién puede revisar y fusionar qué, y cómo se realiza una versión. En resumen: master está protegido. Cada PR necesita CI verde (pruebas, lint, 100% de cobertura de parches) y pasa por las revisiones automatizadas (Cursor, CodeRabbit). Luego necesita la aprobación de un revisor humano que esté autorizado para aprobar los archivos que toca, y se fusiona a través de la cola de fusión.

Hoy, tres personas pueden revisar y fusionar PR en Gladys: yo, @cicoub13 y @bertrandda.

Para ser honesto contigo: Gladys está creciendo muy rápido en este momento. Nunca hemos tenido tantos contribuyentes, integraciones y PR al mismo tiempo. Todavía estamos encontrando nuestro camino, y se nota en el proceso. Lo vamos a mejorar.

También hay un plazo personal por mi parte: pronto voy a ser padre, y estaré ausente durante aproximadamente 2 meses de licencia de paternidad (más información aquí). Suelo ser muy rápido para revisar PR, pero en este momento me estoy centrando en unos pocos temas de muy alta prioridad antes de irme: los que liberan a Gladys de depender de mí (integraciones externas y la organización descrita en MAINTAINERS.md). Por eso algunos PR están esperando más de lo habitual.

Mientras tanto, @cicoub13 y @bertrandda pueden revisar PR para correcciones de errores y cambios en integraciones internas, por lo que no necesitan esperar por mí.

Estoy muy motivado para llevar a Gladys hacia buenas prácticas de gestión de proyectos de código abierto: documentación más clara del proceso, más personas con derechos de revisión, un camino más predecible desde « PR abierto » hasta « PR fusionado ». Comentarios como el tuyo ayudan mucho. Si crees que falta algo o no está claro en MAINTAINERS.md, ¡avísanos!

Gracias de nuevo por tu participación :folded_hands:

@pierre-gilles Gracias por tu respuesta esclarecedora. Por favor, no lo tomes como una crítica, sino como un interés sincero por entender las cosas y, si es posible, mejorarlas. Pero creo que así lo has entendido también :slight_smile:

Cuando tenga tiempo, revisaré todo esto y veré en qué puntos puedo apoyar también a @cicoub13 y @bertrandda. Tienes razón… se nota que están pasando muchas cosas a la vez y no se puede seguir el ritmo. Por eso, donde pueda, ofrezco mi ayuda con gusto.

En cuanto a tu permiso de paternidad: la familia siempre va primero. Lo he tenido que aprender muy a mi pesar. Por eso no quiero retenerte más. Arregla lo que sea necesario y, por lo demás, disfruta del tiempo que viene, porque no volverá.

Si necesitas ayuda o puedes ser apoyado en algo, avísame cuando quieras. ¡Mucha suerte! :baby:

Muchas gracias @stefanbauer, y no te preocupes en absoluto, no lo tomé como una crítica. Preguntas como las tuyas son exactamente lo que nos ayuda a mejorar, así que por favor sigue haciéndolas :slightly_smiling_face:

Y gracias por tus amables palabras sobre la familia :folded_hands:

Una cosa importante a tener en cuenta sobre el rumbo de Gladys: la mayoría del nuevo desarrollo ahora ocurre a través de integraciones externas. Cualquiera puede construir y publicar una integración, un widget, una acción de escena o un disparador, sin esperar a que una PR sea revisada y fusionada en el núcleo. El núcleo tiene como objetivo ser una base estable: correcciones, fiabilidad y los contratos en los que se basan las integraciones externas, en lugar de un lugar donde cada nueva función tenga que aterrizar. Por lo tanto, si tienes una idea para una nueva función o integración, una integración externa es a menudo la forma más rápida de ponerla en manos de los usuarios.

Tu oferta de ayuda es muy bienvenida, y hay mucho que puedes hacer de inmediato, sin ningún derecho especial.

En el foro:

  • Responder preguntas de los nuevos usuarios, ayudar a las personas a depurar su configuración y verificar si un problema reportado es realmente un error antes de que se convierta en un problema de GitHub.
  • Ayudar a las personas a convertir sus ideas en solicitudes de características bien escritas, o señalarles una integración externa existente.

Esto es tan valioso como el código: cada pregunta que la comunidad responde es tiempo que podemos dedicar a hacer avanzar a Gladys.

En GitHub:

  • Revisar PR abiertas: cualquiera puede dejar una revisión o comentarios. Incluso si no cuenta como la aprobación final, un segundo par de ojos ahorra mucho tiempo para @cicoub13 y @bertrandda. Ellos pueden entonces centrarse en lo que realmente necesita su aprobación.
  • Probar PR: verificar que una corrección realmente funciona en tu configuración y decirlo en la PR es muy valioso, especialmente para integraciones que no podemos probar nosotros mismos.
  • Ayudar a triar problemas: detectar duplicados, pedir información faltante, verificar si un error puede reproducirse.

Así es como MAINTAINERS.md describe el camino: los colaboradores activos se unen al equipo de triaje, luego al equipo central una vez que han revisado y sido revisados lo suficiente. Por lo tanto, si empiezas a ayudar, ¡ya estás en ese camino!

Gracias de nuevo por tu apoyo, realmente ayuda :folded_hands:

El problema es que siempre has gestionado casi todo tú solo, así que se ha convertido en una costumbre etiquetarte.
Después, es cierto que si recibes montones de notificaciones al final, no las miras todas o no las miras en absoluto.
Gracias a @cicoub13 y @bertrandda por aceptar ayudarte en esta tarea.

Sin mencionar las notificaciones de GitHub :sweat_smile: