Gobernanza y comunidad.
Wombat es una iniciativa impulsada por la comunidad y neutral respecto al proveedor, con una gobernanza clara y transparente inspirada en modelos open source consolidados como la CNCF. Cada decisión es trazable. Cada rol tiene un mandato.
Hecho para durar, abierto por defecto.
Tres principios que definen la gobernanza de Wombat: lo bastante ligera para avanzar rápido y lo bastante estructurada para escalar.
Decisiones mediante RFC
Todo cambio importante pasa por una Request for Comments: redactada en público, revisada por la comunidad y decidida con justificación. Sin actualizaciones silenciosas ni decisiones opacas de proveedores. El historial es la gobernanza.
Transparente y trazable
La hoja de ruta, los debates, las votaciones y las decisiones se documentan públicamente en GitHub. Cualquiera puede seguir el razonamiento, cuestionar una decisión o proponer una alternativa, siempre con el mismo proceso.
Siempre neutral
Ninguna empresa controla Wombat. Los roles de gobernanza siguen el principio de «primero los contribuidores activos» y un equilibrio neutral entre proveedores. La composición del TSC, las cartas de los grupos de trabajo y el grupo asesor lo garantizan por diseño.
La gobernanza de un vistazo.
Deliberadamente ligera pero escalable, pensada para una comunidad en crecimiento. Las decisiones pasan por RFC, revisiones y votaciones documentadas.
Transparencia: GitHub · RFC · Actas de reuniones
Modelo de gobernanza (inspirado en la CNCF).
Seis roles y mecanismos claramente definidos, cada uno con su alcance, responsabilidad y proceso.
Technical Steering Committee
Responsable de la dirección técnica, las decisiones de arquitectura y la aprobación de RFC. Elegido entre los contribuidores activos. Mandatos renovables de 12 meses.
Equipo de maintainers
Mantiene los repositorios principales, realiza revisiones y garantiza la coherencia y la calidad. Nombrado por 12 meses, renovable según la actividad.
Grupos de trabajo
Grupos temáticos para pilares, puntuación, controles y arquitecturas de referencia. Trabajan en abierto mediante issues de GitHub y RFC. Cualquiera puede proponer un grupo.
User Advisory Group
Aporta perspectivas reales de proyectos, operaciones y auditorías. Prioriza la relevancia: garantiza que el framework refleje la realidad de producción, no solo la teoría.
Público por defecto
La hoja de ruta, los debates, las votaciones y las decisiones se documentan de forma pública y trazable en GitHub. No hay canales privados de decisión para cambios del framework.
Proceso RFC
Borrador → revisión de la comunidad → decisión → implementación. Cada decisión importante se justifica y se enlaza con su hilo de discusión.
Roles, mandatos y expectativas.
Unas reglas claras hacen que la gobernanza sea justa y predecible. Así se toman las decisiones y así funcionan los roles.
Mandatos de los maintainers
Nombrados por 12 meses, renovables cuando hay implicación y actividad de revisión y no existen objeciones fundadas.
Inactividad: Tras 90 días sin actividad, el estado puede pasar a «emérito» tras un aviso y una nota transparente. La reactivación es posible en cualquier momento.
Mandatos del TSC
Los miembros del TSC tienen mandatos de 12 meses , renovables. La composición sigue el principio de «primero los contribuidores activos» y un equilibrio neutral entre proveedores. Los roles y responsabilidades están documentados públicamente.
Crear un grupo de trabajo
Cualquiera puede proponer un grupo. Se necesita: una carta (objetivo, alcance, entregables), líder(es), un canal de comunicación y un maintainer patrocinador.
Los resultados de los grupos vuelven a los repositorios principales como PR y RFC.
Lazy consensus
Para cambios menores: la propuesta se publica con 5 días hábiles para su revisión. Sin objeciones fundadas → aceptada.
Un «bloqueo» debe justificarse y proponer una solución o un ajuste alternativo.
Quórum y votación
Para decisiones de mayor calado (nuevo pilar, cambios incompatibles, cambios de carta), vota el TSC:
- Quórum: al menos 60% de los miembros activos del TSC
- Mayoría: mayoría simple de los votos emitidos
- Mínimo: al menos 3 votos si el TSC es pequeño
- Conflictos: los miembros con conflicto de intereses se abstienen
Expectativas
Actuar con neutralidad respecto al proveedor, priorizar los intereses de la comunidad, documentar las decisiones, comunicarse con respeto (código de conducta) y comunicar los temas de seguridad de forma responsable por los canales definidos.
¿Dónde se toman las decisiones?
RFC para cambios grandes · ADR y notas para decisiones de arquitectura · Issues y PR para la implementación. Cada decisión remite al debate que la originó.
Dónde se reúne la comunidad.
El proyecto nació en el contexto de la Cloud Native Conference y de la comunidad CCC existente. El objetivo: consolidar la experiencia práctica y hacerla evolucionar en abierto.
Intercambio en conferencias: charlas, paneles y sesiones Birds-of-a-Feather en las que los ingenieros comparten retos y patrones reales.
Talleres prácticos sobre modelos de madurez, puntuación e implementación: los conceptos del framework convertidos en práctica de ingeniería.
Sesiones públicas sobre la hoja de ruta y los borradores de RFC abiertos: cualquiera puede asistir, comentar y decidir qué se construye después.
Cómo puedes contribuir.
No hay un tamaño mínimo de contribución. Cada caso de uso compartido, cada revisión y cada comentario en una RFC hace avanzar el framework.
Comparte casos de uso
¿Qué retos afrontas en tus proyectos cloud? ¿Qué patrones funcionan y cuáles no? La experiencia práctica es la aportación más valiosa que puede recibir el framework.
Propón criterios y controles
Aportaciones para modelos de madurez y cuestionarios: ¿qué hay que comprobar sí o sí? Los nuevos controles, criterios de puntuación y patrones de evaluación empiezan aquí.
Revisa y da feedback
Revisa patrones de arquitectura y modelos de referencia en cuanto a coherencia, viabilidad y compromisos. Las RFC abiertas siempre necesitan perspectivas de ingeniería bien pensadas.
Documentación y traducciones
Mejora, amplía y traduce el contenido a otros idiomas. Una buena documentación es la mitad del valor, y siempre hace falta.
Únete a un grupo de trabajo
Colabora en pilares, puntuación, controles o arquitecturas de referencia, de forma transparente en GitHub. Los grupos de trabajo hacen crecer el framework en sprints enfocados y con responsables claros.
Ponentes y sesiones
Presenta temas a los CFP, da charlas u organiza BoF en conferencias. Los ejemplos prácticos presentados en público influyen en el framework más que cualquier RFC por sí sola.
Trazable, justo, abierto.
La gobernanza es una práctica viva. Mantenemos procesos ligeros pero claros para que Wombat crezca con la comunidad sin perder la rendición de cuentas.