Gouvernance et communauté.
Wombat est une initiative communautaire et neutre vis-à-vis des fournisseurs, avec une gouvernance claire et transparente inspirée de modèles open source éprouvés comme la CNCF. Chaque décision est traçable. Chaque rôle a un mandat.
Conçu pour durer, ouvert par défaut.
Trois principes guident la gouvernance de Wombat : assez légère pour avancer vite, assez structurée pour passer à l'échelle.
Des décisions par RFC
Tout changement important passe par une Request for Comments : rédigée en public, relue par la communauté et décidée de manière motivée. Pas de mise à jour silencieuse, pas de choix opaque d'un fournisseur. L'historique fait office de gouvernance.
Transparent et traçable
Feuille de route, discussions, votes et décisions sont documentés publiquement sur GitHub. Chacun peut suivre le raisonnement, contester une décision ou proposer une alternative, toujours selon le même processus.
Toujours neutre
Aucune entreprise ne contrôle Wombat. Les rôles de gouvernance suivent le principe « contributeurs actifs d'abord » et un équilibre neutre entre fournisseurs. La composition du TSC, les chartes des groupes de travail et le groupe consultatif le garantissent par conception.
La gouvernance en bref.
Volontairement légère mais évolutive, conçue pour une communauté en croissance. Les décisions passent par des RFC, des relectures et des votes documentés.
Transparence : GitHub · RFC · Comptes rendus
Modèle de gouvernance (inspiré de la CNCF).
Six rôles et mécanismes clairement définis, chacun avec son périmètre, sa responsabilité et son processus.
Technical Steering Committee
Responsable de l'orientation technique, des décisions d'architecture et de l'approbation des RFC. Élu parmi les contributeurs actifs. Mandats renouvelables de 12 mois.
Équipe des mainteneurs
Maintient les dépôts principaux, effectue les relectures et garantit cohérence et qualité. Nommée pour 12 mois, renouvelable selon l'activité.
Groupes de travail
Des groupes thématiques sur les piliers, le scoring, les contrôles et les architectures de référence. Ils travaillent en public via les issues GitHub et les RFC. Tout le monde peut proposer un groupe.
User Advisory Group
Apporte des retours concrets issus des projets, des opérations et des audits. Privilégie la pertinence : le framework doit refléter la réalité de la production, pas seulement la théorie.
Public par défaut
Feuille de route, discussions, votes et décisions sont documentés publiquement et de façon traçable sur GitHub. Aucun canal de décision privé pour les évolutions du framework.
Processus RFC
Brouillon → relecture communautaire → décision → mise en œuvre. Chaque décision importante est motivée et reliée à son fil de discussion.
Rôles, mandats et attentes.
Des règles claires rendent la gouvernance équitable et prévisible. Voici comment les décisions sont prises et comment fonctionnent les rôles.
Mandat des mainteneurs
Nommés pour 12 mois, renouvelables en cas d'engagement et d'activité de relecture, et en l'absence d'objection fondée.
Inactivité : Après 90 jours sans activité, le statut peut passer à « émérite » après une relance et une note transparente. Une réactivation est possible à tout moment.
Mandat du TSC
Les membres du TSC siègent pour des mandats de 12 mois , renouvelables. La composition suit le principe « contributeurs actifs d'abord » et un équilibre neutre entre fournisseurs. Les rôles et responsabilités sont documentés publiquement.
Créer un groupe de travail
Tout le monde peut proposer un groupe. Il faut : une charte (objectif, périmètre, livrables), un ou plusieurs responsables, un canal de communication et un mainteneur parrain.
Les livrables des groupes reviennent dans les dépôts principaux sous forme de PR et de RFC.
Lazy consensus
Pour les petits changements : une proposition est publiée avec 5 jours ouvrés pour relecture. Aucune objection fondée → acceptée.
Un « blocage » doit être motivé et proposer une solution ou un ajustement alternatif.
Quorum et vote
Pour les décisions plus importantes (nouveau pilier, changements incompatibles, modification de charte), le TSC vote :
- Quorum : au moins 60% des membres actifs du TSC
- Majorité : majorité simple des voix exprimées
- Minimum : au moins 3 voix si le TSC est restreint
- Conflits : les membres en conflit d'intérêts s'abstiennent
Attentes
Agir de façon neutre vis-à-vis des fournisseurs, privilégier l'intérêt de la communauté, documenter les décisions, communiquer avec respect (code de conduite) et signaler les sujets de sécurité de manière responsable via les canaux prévus.
Où les décisions sont-elles prises ?
RFC pour les changements importants · ADR et notes pour les décisions d'architecture · Issues et PR pour la mise en œuvre. Chaque décision renvoie à la discussion qui l'a précédée.
Où la communauté se retrouve.
Le projet est né dans le contexte de la Cloud Native Conference et de la communauté CCC existante. L'objectif : consolider l'expérience de terrain et la faire évoluer en public.
Des échanges en conférence : talks, tables rondes et sessions Birds-of-a-Feather où des ingénieurs partagent leurs vrais défis et leurs patterns.
Des ateliers pratiques sur les modèles de maturité, le scoring et la mise en œuvre : les concepts du framework deviennent pratique d'ingénierie.
Des sessions publiques sur la feuille de route et les RFC en cours : chacun peut y assister, commenter et influencer la suite.
Comment contribuer.
Il n'y a pas de taille minimale de contribution. Chaque cas d'usage partagé, chaque relecture, chaque commentaire sur une RFC fait avancer le framework.
Partager des cas d'usage
Quels défis rencontrez-vous dans vos projets cloud ? Quels patterns fonctionnent, et lesquels non ? L'expérience de terrain est l'apport le plus précieux pour le framework.
Proposer des critères et des contrôles
Des apports pour les modèles de maturité et les questionnaires : que faut-il vérifier dans tous les cas ? Nouveaux contrôles, critères de scoring et patterns d'évaluation commencent ici.
Relire et donner un retour
Relisez des patterns d'architecture et des modèles de référence sous l'angle de la cohérence, de l'applicabilité et des compromis. Les RFC ouvertes ont toujours besoin de regards d'ingénieurs réfléchis.
Documentation et traductions
Améliorez, enrichissez et traduisez le contenu dans d'autres langues. Une bonne documentation, c'est la moitié de la valeur, et elle est toujours recherchée.
Rejoindre un groupe de travail
Contribuez aux piliers, au scoring, aux contrôles ou aux architectures de référence, en toute transparence sur GitHub. Les groupes de travail font grandir le framework par sprints ciblés et responsables.
Intervenants et sessions
Proposez des sujets aux CFP, donnez des talks ou animez des BoF en conférence. Des exemples concrets présentés en public façonnent le framework plus qu'une RFC seule.
Traçable, équitable, ouvert.
La gouvernance est une pratique vivante. Nous gardons des processus légers mais clairs, pour que Wombat grandisse avec la communauté sans perdre en responsabilité.