Contribuire.

Wombat vive di contributi. Che tu scriva codice, migliori la documentazione, revisioni RFC o condivida esperienze da progetti reali, ogni contributo dà forma al framework.

6
Modi per contribuire
4
Maintainer principali
2
Contributor del codice
0
Dimensione minima del contributo

Modi per contribuire.

Codice, contenuti, community: scegli ciò che si adatta alle tue competenze e al tuo tempo.

PR e issue

Correggi bug, implementa controlli, migliora gli strumenti. Ogni PR viene revisionata da un maintainer e collegata a una decisione.

Documentazione e pattern

Scrivi documentazione dei pilastri, architetture di riferimento, pattern di best practice o esempi concreti da progetti reali.

Revisione degli RFC

Commenta gli RFC aperti, proponi alternative o vota le decisioni sul framework. Ogni voce conta, soprattutto quella di chi ha esperienza sul campo.

Localizzazione

Aiuta a tradurre i contenuti in tedesco, inglese o altre lingue. Wombat deve essere accessibile alla community cloud globale.

Gruppi di lavoro

Unisciti a un gruppo di lavoro, o proponine uno, su un pilastro specifico, sul modello di punteggio, sulla libreria dei controlli o su un'architettura di riferimento.

Talk e BoF

Presenta Wombat a una conferenza, organizza una sessione Birds-of-a-Feather o tieni un workshop per la community. L'esperienza pratica vale oro.

Chi lo costruisce.

Persone vere, commit veri: nessun muro di loghi, nessuna foto di stock del team.

Artem Lajko
Maintainer

Founder / Core maintainer

Sascha Lewandowski
Maintainer

Founder / Core maintainer

Sebastian Meyer
Maintainer

Founder / Core maintainer

Tim Urlaub
Maintainer

Founder / Core maintainer

Community Impact Contributors
Maximilian Hille
Zusätzliche Einsichten in Business Usecases
Tutti i contributor del codice

Sincronizzato da GitHub · 12 commit in totale

Per iniziare.

Quattro passi da nuovo arrivato a contributor.

  1. Esplora l'organizzazione GitHub

    Sfoglia le issue aperte con l'etichetta good first issue o help wanted su github.com/waf2p. Nessuna issue adatta? Aprine una e descrivi cosa vuoi affrontare.

  2. Presentati su Slack

    Unisciti alla community su Slack, saluta in #general, fai domande e scopri quale gruppo di lavoro si adatta al tuo profilo e ai tuoi interessi.

  3. Fork → branch → PR

    Fai il fork del repository giusto, crea un branch di funzionalità e apri una pull request. Un maintainer la revisionerà, ti darà feedback e ti guiderà nel processo.

  4. Modifiche più grandi? Prima apri un RFC

    Per nuovi pilastri, modifiche incompatibili, cambiamenti al punteggio o alla governance, scrivi una bozza di RFC in GitHub Discussions. La community la esamina prima dell'implementazione. Così le decisioni restano tracciabili.

Gruppi di lavoro.

I gruppi di lavoro sono team tematici che sviluppano parti specifiche di Wombat. Chiunque può proporne uno: servono solo uno statuto, almeno un lead e un maintainer che faccia da sponsor.

Trova un GdL

Consulta le proposte di gruppi aperte in GitHub Discussions e unisciti al canale Slack corrispondente. Puoi contribuire senza un impegno a tempo pieno.

Avvia un GdL

Scrivi uno statuto in una discussione GitHub, trova un maintainer sponsor e annuncialo su Slack. Un gruppo può avere qualsiasi ambito: un singolo pilastro, una questione di tooling, un approccio al punteggio.

Produci risultati

I risultati dei gruppi tornano come PR e RFC. Ogni risultato è pubblico, tracciabile e citabile, in linea con i principi di trasparenza di Wombat.

Ciclo di vita delle funzionalità.

Ogni capacità di Wombat segue un ciclo di vita chiaro. Ogni fase è subordinata al processo RFC/ADR, così gli utenti sanno sempre quanto è matura una funzionalità e cosa aspettarsi prima di adottarla.

Closed Alpha

Esplorazione privata

Un piccolo gruppo di early adopter testa la capacità in ambienti controllati. API, modello di punteggio o interfaccia CLI sono volutamente instabili e possono cambiare senza preavviso.

Come ci si arriva
  • Un RFC in bozza o aperto definisce l'esperimento
  • Gruppo di accesso anticipato solo su invito
  • Il feedback guida iterazioni rapide
Vedi gli RFC in bozza →
Alpha

Test pubblico

La capacità è disponibile per chiunque voglia provarla. Le interfacce sono in gran parte stabili, ma sono ancora possibili modifiche incompatibili in base al feedback della community.

Come ci si arriva
  • RFC accettato con ambito alpha
  • Documentazione pubblica e note di rilascio disponibili
  • GitHub Discussions raccoglie il feedback
Partecipa alle discussioni alpha →
Beta

Uso in produzione

La capacità è completa e pronta per la produzione nei casi d'uso documentati. Sono ancora possibili piccoli aggiustamenti, ma le modifiche incompatibili richiedono una guida esplicita alla migrazione.

Come ci si arriva
  • RFC accettato e implementazione unita
  • Un ADR documenta i criteri di prontezza per la produzione
  • Revisione di sicurezza, prestazioni e compatibilità superata
Segui gli RFC accettati →
GA

Disponibilità generale

La capacità è pienamente supportata, coperta dalla policy di stabilità e consigliata a tutti. Viene mantenuta con aggiornamenti retrocompatibili e periodi di deprecazione chiari.

Come ci si arriva
  • Lo stato dell'RFC passa a implemented
  • Un ADR finale ratifica il contratto stabile
  • Inserimento nel ciclo di rilascio ufficiale
Vedi gli RFC implementati →

Ogni fase è collegata al processo RFC/ADR. Quando un RFC viene accettato attiva la fase alpha o beta; quando viene contrassegnato come implemented , la capacità è pronta per la GA. Segui il quadro completo nel tracker degli RFC o proponi la prossima modifica in GitHub Discussions.

Il processo RFC.

Le modifiche rilevanti passano per un RFC (Request for Comments). Il processo è leggero ma garantisce che ogni decisione sia revisionata dalla community e documentata.

Bozza
Apri una discussione su GitHub con la tua proposta
→
Revisione
Community e maintainer commentano e affinano
→
Decisione
TSC o lazy consensus, documentato pubblicamente
→
Implementazione
PR unita, changelog aggiornato

Nessun contributo è troppo piccolo.

Una correzione di un refuso, un commento chiarificatore, una revisione: tutto fa avanzare il framework. Wombat si costruisce in pubblico e la community è sempre aperta.