Governance e community.
Wombat è un'iniziativa guidata dalla community e neutrale rispetto ai fornitori, con una governance chiara e trasparente ispirata a modelli open source consolidati come la CNCF. Ogni decisione è tracciabile. Ogni ruolo ha un mandato.
Costruito per durare, aperto per impostazione.
Tre principi definiscono la governance di Wombat: abbastanza leggera da muoversi in fretta, abbastanza strutturata da scalare.
Decisioni tramite RFC
Ogni modifica rilevante passa per una Request for Comments: redatta in pubblico, revisionata dalla community e decisa con una motivazione. Nessun aggiornamento silenzioso, nessuna scelta opaca dei fornitori. La cronologia è la governance.
Trasparente e tracciabile
Roadmap, discussioni, votazioni e decisioni sono documentate pubblicamente su GitHub. Chiunque può seguire il ragionamento, contestare una decisione o proporre un'alternativa, sempre con lo stesso processo.
Sempre neutrale
Nessuna singola azienda controlla Wombat. I ruoli di governance seguono il principio «prima i contributor attivi» e un equilibrio neutrale tra fornitori. La composizione del TSC, gli statuti dei gruppi di lavoro e l'Advisory Group lo garantiscono by design.
La governance in sintesi.
Volutamente snella ma scalabile, pensata per una community in crescita. Le decisioni passano per RFC, revisioni e votazioni documentate.
Trasparenza: GitHub · RFC · Verbali delle riunioni
Modello di governance (ispirato alla CNCF).
Sei ruoli e meccanismi chiaramente definiti, ciascuno con ambito, responsabilità e processo propri.
Technical Steering Committee
Responsabile della direzione tecnica, delle decisioni architetturali e dell'approvazione degli RFC. Eletto tra i contributor attivi. Mandati rinnovabili di 12 mesi.
Team dei maintainer
Gestisce i repository principali, esegue le revisioni e garantisce coerenza e qualità. Nominato per 12 mesi, rinnovabile in base all'attività.
Gruppi di lavoro
Gruppi tematici su pilastri, punteggi, controlli e architetture di riferimento. Lavorano apertamente tramite issue GitHub e RFC. Chiunque può proporre un gruppo.
User Advisory Group
Porta prospettive concrete da progetti, operazioni e audit. Dà priorità alla rilevanza: il framework deve riflettere la realtà della produzione, non solo la teoria.
Pubblico per impostazione
Roadmap, discussioni, votazioni e decisioni sono documentate in modo pubblico e tracciabile su GitHub. Nessun canale decisionale privato per le modifiche al framework.
Processo RFC
Bozza → revisione della community → decisione → implementazione. Ogni decisione rilevante è motivata e collegata alla relativa discussione.
Ruoli, mandati e aspettative.
Regole chiare rendono la governance equa e prevedibile. Ecco come si prendono le decisioni e come funzionano i ruoli.
Mandato dei maintainer
Nominati per 12 mesi, rinnovabili in presenza di impegno e attività di revisione e in assenza di obiezioni fondate.
Inattività: Dopo 90 giorni senza attività, lo stato può passare a «emerito» dopo un sollecito e una nota trasparente. La riattivazione è possibile in qualsiasi momento.
Mandato del TSC
I membri del TSC restano in carica per 12 mesi , con mandato rinnovabile. La composizione segue il principio «prima i contributor attivi» e un equilibrio neutrale tra fornitori. Ruoli e responsabilità sono documentati pubblicamente.
Avviare un gruppo di lavoro
Chiunque può proporre un gruppo. Servono: uno statuto (obiettivo, ambito, risultati), uno o più lead, un canale di comunicazione e un maintainer sponsor.
I risultati dei gruppi tornano nei repository principali come PR e RFC.
Lazy consensus
Per le modifiche minori: una proposta viene pubblicata con 5 giorni lavorativi per la revisione. Nessuna obiezione fondata → accettata.
Un «blocco» deve essere motivato e proporre una soluzione o una modifica alternativa.
Quorum e votazione
Per le decisioni più importanti (nuovo pilastro, modifiche incompatibili, modifiche allo statuto) vota il TSC:
- Quorum: almeno 60% dei membri attivi del TSC
- Maggioranza: maggioranza semplice dei voti espressi
- Minimo: almeno 3 voti se il TSC è ristretto
- Conflitti: i membri in conflitto di interessi si astengono
Aspettative
Agire in modo neutrale rispetto ai fornitori, dare priorità agli interessi della community, documentare le decisioni, comunicare con rispetto (codice di condotta) e segnalare responsabilmente le questioni di sicurezza tramite i canali previsti.
Dove si prendono le decisioni?
RFC per le modifiche più ampie · ADR e note per le decisioni architetturali · Issue e PR per l'implementazione. Ogni decisione rimanda alla discussione che l'ha generata.
Dove si incontra la community.
Il progetto è nato nel contesto della Cloud Native Conference e della community CCC esistente. L'obiettivo: consolidare l'esperienza pratica e farla evolvere in modo aperto.
Confronto alle conferenze: talk, panel e sessioni Birds-of-a-Feather in cui gli ingegneri condividono sfide e pattern reali.
Workshop pratici su modelli di maturità, punteggi e implementazione: i concetti del framework diventano pratica ingegneristica.
Sessioni pubbliche sulla roadmap e sulle bozze di RFC aperte: chiunque può partecipare, commentare e contribuire a decidere cosa costruire dopo.
Come puoi contribuire.
Non c'è una dimensione minima per i contributi. Ogni caso d'uso condiviso, ogni revisione, ogni commento a un RFC fa avanzare il framework.
Condividi casi d'uso
Quali sfide affronti nei progetti cloud? Quali pattern funzionano e quali no? L'esperienza pratica è il contributo più prezioso che il framework possa ricevere.
Proponi criteri e controlli
Contributi per modelli di maturità e questionari: cosa va verificato in ogni caso? Nuovi controlli, criteri di punteggio e pattern di valutazione nascono qui.
Revisiona e dai feedback
Revisiona pattern architetturali e modelli di riferimento per coerenza, praticità e compromessi. Gli RFC aperti hanno sempre bisogno di prospettive ingegneristiche ponderate.
Documentazione e traduzioni
Migliora, amplia e traduci i contenuti in altre lingue. Una buona documentazione vale metà del valore, ed è sempre richiesta.
Unisciti a un gruppo di lavoro
Contribuisci a pilastri, punteggi, controlli o architetture di riferimento, in modo trasparente su GitHub. I gruppi di lavoro fanno crescere il framework con sprint mirati e responsabili.
Speaker e sessioni
Proponi temi alle CFP, tieni talk o organizza BoF alle conferenze. Esempi pratici presentati in pubblico danno forma al framework più di qualsiasi RFC da solo.
Tracciabile, equo, aperto.
La governance è una pratica viva. Manteniamo processi snelli ma chiari, così Wombat può crescere con la community senza perdere responsabilità.