Façons de contribuer.
Code, contenu, communauté : choisissez ce qui correspond à vos compétences et à votre temps.
PR et issues
Corrigez des bugs, implémentez des contrôles, améliorez l'outillage. Chaque PR est relue par un mainteneur et reliée à une décision.
Docs et patterns
Rédigez la documentation des piliers, des architectures de référence, des bonnes pratiques ou des exemples concrets issus de vrais projets.
Relecture des RFC
Commentez les RFC ouvertes, proposez des alternatives ou votez sur les décisions du framework. Chaque voix compte, surtout celle du terrain.
Localisation
Aidez à traduire le contenu en allemand, en anglais ou dans d'autres langues. Wombat doit être accessible à toute la communauté cloud mondiale.
Groupes de travail
Rejoignez ou proposez un groupe de travail sur un pilier, le modèle de scoring, la bibliothèque de contrôles ou une architecture de référence.
Talks et BoF
Présentez Wombat en conférence, animez une session Birds-of-a-Feather ou un atelier communautaire. L'expérience pratique vaut de l'or.
Qui le construit.
De vraies personnes, de vrais commits : pas de mur de logos, pas de photos d'équipe de banque d'images.
Synchronisé depuis GitHub · 12 commits au total
lewandos 
t1murl Pour commencer.
Quatre étapes pour passer de nouveau venu à contributeur.
-
Explorez l'organisation GitHub
Parcourez les issues ouvertes portant le label
good first issueouhelp wantedsur github.com/waf2p. Aucune issue ? Ouvrez-en une et décrivez ce que vous voulez traiter. -
Présentez-vous sur Slack
Rejoignez la communauté sur Slack, dites bonjour dans
#general, posez vos questions et trouvez le groupe de travail qui correspond à votre profil et à vos centres d'intérêt. -
Fork → branche → PR
Forkez le dépôt concerné, créez une branche de fonctionnalité et ouvrez une pull request. Un mainteneur la relira, vous fera un retour et vous accompagnera dans le processus.
-
Changements plus importants ? Ouvrez d'abord une RFC
Pour de nouveaux piliers, des changements incompatibles, des évolutions du scoring ou de la gouvernance, rédigez une RFC dans GitHub Discussions. La communauté la relit avant le début de la mise en œuvre. Les décisions restent ainsi traçables.
Groupes de travail.
Les groupes de travail sont des équipes thématiques qui construisent des parties précises de Wombat. Tout le monde peut en proposer un : il suffit d'une charte, d'au moins un responsable et d'un mainteneur parrain.
Trouver un GT
Consultez les propositions de groupes ouvertes dans GitHub Discussions et rejoignez le canal Slack correspondant. Vous pouvez contribuer sans engagement à plein temps.
Lancer un GT
Rédigez une charte dans une discussion GitHub, trouvez un mainteneur parrain et annoncez-le sur Slack. Un groupe peut porter sur n'importe quel périmètre : un pilier, une question d'outillage, une approche de scoring.
Livrer des résultats
Les résultats des groupes reviennent sous forme de PR et de RFC. Chaque résultat est public, traçable et citable, conformément aux principes de transparence de Wombat.
Cycle de vie des fonctionnalités.
Chaque capacité de Wombat suit un cycle de vie clair. Chaque étape est conditionnée par le processus RFC/ADR, pour que les utilisateurs sachent toujours quel est le niveau de maturité d'une fonctionnalité et à quoi s'attendre avant de l'adopter.
Explorer en privé
Un petit groupe d'early adopters teste la capacité dans des environnements contrôlés. L'API, le modèle de scoring ou l'interface CLI sont volontairement instables et peuvent changer sans préavis.
- Une RFC en brouillon ou ouverte définit l'expérimentation
- Cohorte d'accès anticipé sur invitation
- Les retours guident des itérations rapides
Tester en public
La capacité est accessible à toute personne qui souhaite l'essayer. Les interfaces sont en grande partie stables, mais des changements incompatibles restent possibles selon les retours de la communauté.
- RFC acceptée avec un périmètre alpha
- Documentation publique et notes de version disponibles
- GitHub Discussions recueille les retours
Utiliser en production
La capacité est complète et prête pour la production dans les cas d'usage documentés. Des ajustements mineurs restent possibles, mais tout changement incompatible exige un guide de migration explicite.
- RFC acceptée et implémentation fusionnée
- Un ADR documente les critères de mise en production
- Revue de sécurité, de performance et de compatibilité réussie
Disponibilité générale
La capacité est entièrement prise en charge, couverte par la politique de stabilité et recommandée à tous. Elle est maintenue avec des mises à jour rétrocompatibles et des périodes de dépréciation claires.
- Le statut de la RFC passe à implemented
- Un ADR final ratifie le contrat stable
- Intégration au cycle de versions officiel
Chaque étape est liée au processus RFC/ADR. Lorsqu'une RFC est acceptée, elle déclenche l'étape alpha ou bêta ; lorsqu'elle est marquée implemented , la capacité est prête pour la GA. Suivez la vue d'ensemble dans le suivi des RFC ou proposez le prochain changement dans GitHub Discussions.
Le processus RFC.
Les changements importants passent par une RFC (Request for Comments). Le processus est léger, mais garantit que chaque décision est relue par la communauté et documentée.
Aucune contribution n'est trop petite.
Une coquille corrigée, un commentaire clarifié, une relecture : tout fait avancer le framework. Wombat se construit en public et la communauté est toujours ouverte.