Communication

Où poser des questions, signaler des bugs, proposer des fonctionnalités et contacter l’équipe.

Si vous souhaitez simplement discuter avec nous, Discord est la solution. Pour tout ce qui nécessite un enregistrement durable (bugs, demandes de fonctionnalités, discussions sur la conception, RFCs), utilisez GitHub.

Discord : le meilleur endroit pour contacter l’équipe

Chat en temps réel. C’est ici que les mainteneurs vivent au quotidien ; le chemin le plus rapide pour obtenir une réponse humaine.

Canaux :

• #general : le salon par défaut
• #help : fils de discussion « Je n’arrive pas à faire fonctionner X » ; le moyen le plus rapide de se débloquer
• #dev : discussion sur le développement en cours
• #releases : annonces, notes de version, avertissements préalables sur les changements incompatibles

Lien d’invitation dans le README du dépôt.

Discord est éphémère : si la conversation aboutit à un bug ou à une idée de fonctionnalité, consignez-la ensuite sous forme d’issue GitHub afin que la trace persiste. Discord sert à la conversation ; GitHub sert de mémoire.

Utilisez un transfert GitHub lorsque Discord produit quelque chose que le projet doit conserver. Créez ou mettez à jour une issue, une discussion, un commentaire de PR ou un document de mainteneur lorsque le fil produit un bug reproductible, une portée de fonctionnalité concrète, une décision d’architecture ou de gouvernance, un engagement de mainteneur, une attribution de responsable, une décision de jalon, un blocage, une solution de contournement, une preuve de validation, une note d’impact sur une version, ou une raison d’exemption pour inactivité. Le transfert n’a besoin que de la décision, des preuves, du responsable lorsqu’il en existe un, et de suffisamment de contexte pour qu’un autre mainteneur puisse continuer sans relire la discussion.

Problèmes GitHub

Pour les bogues, les demandes de fonctionnalités et tout ce qui doit être suivi.

• Rapports de bogues : utilisez le modèle de bogue (.github/ISSUE_TEMPLATE/bug_report.yml). Incluez zeroclaw --version, le système d’exploitation et la sortie de zeroclaw doctor.
• Demandes de fonctionnalités : utilisez le modèle de fonctionnalité (.github/ISSUE_TEMPLATE/feature_request.yml). Concentrez-vous sur la valeur pour l’utilisateur et les contraintes ; les détails d’implémentation relèvent des RFC ou de la discussion de PR.
• RFC : voir le processus RFC.

Recherchez avant de créer un ticket. Les doublons sont fusionnés ; la barre de recherche est votre alliée.

Discussions GitHub

Pour les fils de discussion destinés à la communauté qui nécessitent plus de permanence que Discord mais qui ne sont pas encore du travail suivi. Les discussions conviennent bien aux questions-réponses, aux idées, à la présentation de projets, aux sondages, aux annonces des mainteneurs et aux fils du type « est-ce que quelqu’un d’autre voit ça ? » qui défileraient et disparaîtraient sur Discord.

Considérez les Discussions comme des conversations communautaires non urgentes. Elles ne font l’objet d’un suivi par les mainteneurs que lorsqu’un responsable ou une cadence de revue est documenté. La routine des mainteneurs et la cadence par défaut sont décrites dans Guide du relecteur : gestion des Discussions.

Les Discussions font partie du système de transfert GitHub, et non un remplacement des issues, RFC, commentaires de PR ou docs des mainteneurs. Déplacez une Discussion vers la surface suivie dès qu’elle produit un bug concret, un périmètre de fonctionnalité, un responsable, un bloqueur, des preuves de validation, une décision de politique ou une exigence de documentation.

Utilisez cette répartition lors du choix d’une surface :

Les catégories de discussion doivent rendre le résultat attendu évident. Utilisez Q&A pour les questions auxquelles il est possible de répondre, Ideas pour les propositions qui nécessitent une mise en forme par la communauté, Show and tell pour les démos, intégrations ou forks en aval liés au projet que les gens souhaitent partager, Polls pour les votes de la communauté, Announcements pour les mises à jour des mainteneurs, et General pour les conversations générales et facilement consultables, l’exploration architecturale précoce, ou la collaboration en aval/fork/entreprise qui ne correspond pas encore à un travail suivi. Si la collaboration en aval devient suffisamment récurrente pour nécessiter sa propre voie supervisée, les mainteneurs pourront ajouter ultérieurement une catégorie dédiée.

Bouclez la boucle lorsqu’une Discussion évolue. Ajoutez un résumé court et un lien vers l’issue, la RFC, la PR ou le document qui porte désormais le résultat. Si la catégorie prend en charge les réponses acceptées, marquez le résumé ou le lien vers le travail suivi comme réponse lorsque cela reflète fidèlement le résultat.

github.com/zeroclaw-labs/zeroclaw/discussions

Contacts des mainteneurs

Toutes les personnes ci-dessous font partie de la Core Team, le rôle de niveau 3 défini dans FND-003. Le statut de membre découle d’une invitation et d’une annonce publique, conformément au §5.1 ; ce tableau est un résumé publié de ces décisions, et non le document qui les établit. Attendez-vous à ce qu’il diffère de l’équipe GitHub core-contributors et de la liste des collaborateurs, qui sont des contrôles d’accès plutôt que des registres d’appartenance : ils incluent des comptes d’automatisation, et l’accès peut être direct, hérité ou en attente. Consultez §5.3 pour savoir quel registre répond à quelle question.

La colonne Focus décrit le domaine de travail de chaque personne, et non le niveau d’autorité qu’elle détient : la Core Team est horizontale. Les décisions courantes reposent sur le consensus tacite, et les modifications de CODEOWNERS, les publications, les résultats de RFC, les modifications de gouvernance et les ajouts à la Core Team requièrent tous un vote explicite de la Core Team, quel que soit le rôle. « Project lead » est un rôle de coordination et d’escalade au sein de la Core Team, et non un échelon supérieur à celle-ci.

Toutes les personnes répertoriées ne relisent pas le code. Acheminez la relecture de code via la colonne Focus et via CODEOWNERS, pas via le niveau.

Les domaines d’intérêt suivent .github/CODEOWNERS, qui constitue l’enregistrement de routage faisant autorité. Ce tableau est le résumé lisible par l’humain ; si les deux divergent, CODEOWNERS prévaut.

Utilisez les @-mentions avec parcimonie, ne mentionnez les mainteneurs de CC que lorsque le problème nécessite réellement leur attention. Par défaut, laissez l’équipe effectuer le triage.

Problèmes de sécurité

Ne signalez pas de problèmes publics pour les vulnérabilités de sécurité.

Signalez de manière privée via le signalement privé de vulnérabilités de GitHub (Security Advisories).

Inclure :

• Versions concernées
• Reproduction (minimale, s’il vous plaît)
• Évaluation des impacts

Nous nous efforçons d’accuser réception sous 48 heures, d’évaluer sous 1 semaine et de livrer un correctif sous 2 semaines pour les problèmes critiques. La divulgation coordonnée est appréciée.

Consultez le fichier SECURITY.md à la racine du dépôt pour connaître la politique complète.

Flux de publication

Abonnez-vous au flux de publication de GitHub pour être notifié des nouvelles versions :

https://github.com/zeroclaw-labs/zeroclaw/releases.atom

Ou suivez le dépôt sur GitHub (Watch → Custom → Releases).

Les notes de version sont également publiées sur Discord #releases et sur le Twitter de la communauté.

Support commercial

Aucune offre n’est proposée. ZeroClaw est maintenu par la communauté. Si vous déployez à grande échelle et souhaitez des SLA, sponsorisez un mainteneur directement ou financez un arrangement de support dédié via l’équipe principale. Contactez-nous à l’adresse hello@zeroclaw.dev.

Retour d’information

Les retours ouverts, « j’ai essayé de faire X et ça semblait incorrect », les observations UX, les réflexions sur la direction trouvent leur place idéale dans un thread sur Discord #general ou #dev lorsqu’une conversation rapide en direct est nécessaire. Utilisez les Discussions GitHub General ou Ideas lorsque le retour doit rester consultable pour une contribution asynchrone de la communauté. Si le thread débouche sur quelque chose de concret, transférez-le vers une issue, une RFC, un commentaire de PR ou la documentation.

Reconnaissance des contributeurs

Toute personne ayant eu une PR fusionnée apparaît dans la liste des contributeurs du dépôt. Pour les contributions substantielles, fonctionnalités, RFC, corrections de bugs importantes, votre pseudo apparaît dans les notes de version.

Voir aussi

• Comment contribuer
• Processus RFC
• Philosophie : ce que le projet cherche à être, afin de savoir ce qui entre dans son périmètre