Gouvernance &Communauté
WAF++ est une initiative communautaire, neutre pour les fournisseurs, dotée d'une gouvernance claire et transparente s'inspirant de modèles ouverts établis comme le CNCF. Chaque décision est traçable. Chaque rôle a un terme.
Construit pour durer, ouvert par défaut
Trois principes qui façonnent la façon dont WAF++ est gouverné — assez léger pour se déplacer rapidement, assez structuré pour s'étendre.
Chaque changement important fait l'objet d'une demande de commentaires — rédigée publiquement, examinée par la collectivité et jugée avec justification. Pas de mises à jour silencieuses, pas de choix de fournisseurs opaques. L'histoire est la gouvernance.
La feuille de route, les discussions, les votes et les décisions sont documentés publiquement sur GitHub. N'importe qui peut suivre le raisonnement, contester une décision, ou proposer une alternative — avec le même processus à chaque fois.
Aucune entreprise ne contrôle WAF++. Les rôles de gouvernance suivent « les contributeurs actifs d'abord » et l'équilibre entre fournisseurs et neutres. La composition du CST, les chartes du Groupe de travail et le Groupe consultatif l'appliquent tous par conception.
La gouvernance en bref
L'intentionnellement maigre mais évolutive — conçue pour une communauté croissante. Les décisions passent par les CRF, les examens et les votes documentés.
Modèle de gouvernance (inspiré par le CCNF)
Six rôles et mécanismes clairement définis, chacun ayant une portée, une responsabilité et un processus précis.
Responsable de la direction technique, des décisions d'architecture et des approbations RFC. Élu parmi les contributeurs actifs. Durées renouvelables de 12 mois.
Préserve les dépôts de base, effectue des examens et assure la cohérence et la qualité. Nommé pour 12 mois, renouvelable en fonction de l'activité.
Groupes thématiques pour les piliers, la notation, les contrôles et les architectures de référence. Travailler ouvertement via les questions GitHub et les RFC. Tout le monde peut proposer un GT.
Apporte des perspectives réelles de projets, d'opérations et d'audits. Accorde la priorité à la pertinence — assure que le cadre reflète la réalité de la production et non pas seulement la théorie.
La feuille de route, les discussions, les votes et les décisions sont documentés publiquement et traçables sur GitHub. Pas de canaux de décision privés pour les changements de cadre.
Ébauche de l'examen communautaire de l'application de la décision de l'étude. Chaque décision importante est justifiée et liée à son fil de discussion.
Rôles, termes et attentes
Des règles claires rendent la gouvernance juste et prévisible. Voici exactement comment les décisions sont prises et comment les rôles fonctionnent.
Conditions du maintien
Nommé pour12 mois, renouvelable lorsque des activités d'engagement et d'examen sont présentes et qu'il n'existe aucune objection fondée.
Inactivité:Après90 jourssans activité, le statut peut être défini comme "émérite" après une note ping et transparente. La réactivation est possible à tout moment.
Termes TSC
Membres du CST12 moistermes, renouvelables. La composition suit « les contributeurs actifs d'abord » et l'équilibre entre les fournisseurs et les fournisseurs. Les rôles et les responsabilités sont documentés publiquement.
Création d ' un groupe de travail
Tout le monde peut proposer un GT. Requis : acharte(objectif, portée, résultats escomptés),plomb(s), un canal de communication,promoteur responsable.
Les sorties du GT reviennent dans la réserve principale sous forme de PR et de RFC.
Un consensus paresseux
Pour les petits changements: une proposition est publiée avec5 jours ouvrablespour examen. Aucune objection fondée → acceptée.
Un "bloc" doit être justifié et proposer une solution ou un ajustement alternatif.
Quorum & vote
Pour les décisions plus importantes (nouveau pilier, rupture des changements, changements de charte), le CST vote :
- Quorum:au moins60%des membres actifs du CST
- Majorité :majorité simple des suffrages exprimés
- Minimum:au moins3vote si le TSC est petit
- Conflits :les membres ayant des conflits d'intérêts s'abstiennent
Attentes
Loi sur les fournisseurs neutres, prioriser les intérêts communautaires, documenter les décisions, communiquer respectueusement (Code de conduite) et signaler les sujets de sécurité de façon responsable par les voies définies.
Où sont prises les décisions?
RFC pour les changements plus importants · MARC et notes pour les décisions relatives à l'architecture · Questions et PR pour la mise en oeuvre. Chaque décision fait référence à la discussion qui l'a menée.
Où la communauté se réunit
Le projet a débuté dans le contexte de la Conférence sur les autochtones de Cloud et de la communauté CCC existante. Le but : consolider l'expérience du monde réel et l'évoluer ouvertement en public.
Échanges lors de conférences — conférences, panels et séances Oiseaux de Feu où les ingénieurs partagent des défis et des modèles réels.
Ateliers pratiques sur les modèles de maturité, la notation et la mise en œuvre pratique — transformer les concepts-cadres en pratiques d'ingénierie.
Les séances publiques sur la feuille de route et les ébauches ouvertes de la RFC — tout le monde peut assister, commenter et façonner ce qui se construit ensuite.
Comment contribuer
Il n'y a pas de contribution minimale. Chaque cas d'utilisation partagé, chaque examen donné, chaque RFC commente fait avancer le cadre.
Quels défis rencontrez-vous dans les projets cloud ? Quels modèles fonctionnent — et qui ne fonctionnent pas? L'expérience du monde réel est l'apport le plus précieux que le cadre puisse obtenir.
Entrée pour les modèles de maturité et les questionnaires : que faut-il vérifier, quoi qu'il arrive ? De nouveaux contrôles, critères de notation et modèles d'évaluation commencent ici.
Examiner les modèles d'architecture et les modèles de référence pour en assurer la cohérence, la praticabilité et les compromis. Les RFC ouverts ont toujours besoin de perspectives d'ingénierie réfléchies.
Améliorer, étendre et traduire le contenu dans d'autres langues. Une bonne documentation est la moitié de la valeur — et toujours en demande.
Aide avec les piliers, le pointage, les commandes ou les architectures de référence – transparentement sur GitHub. Les groupes de travail sont la façon dont le cadre se développe en sprints ciblés et responsables.
Apporter des sujets aux PFC, donner des conférences, ou accueillir des BoF lors de conférences. Des exemples concrets du monde réel présentés publiquement façonnent le cadre plus que n'importe quel seul RFC.
Traçable, juste, ouvert.
La gouvernance est une pratique vécue. Nous gardons les processus légers mais clairs — de sorte que WAF++ puisse croître avec la communauté sans perdre la responsabilité.
