Contribute to Dweve AI Infrastructure

Postes à temps plein en ingénierie et produit. Télétravail prioritaire au sein de l'UE.

Renseignez-vous sur le parcours du projet, la licence et les conditions de contribution avant d'envoyer votre travail.

Notes de version, analyses approfondies et post-mortems honnêtes de l'équipe.

Références API, guides d'intégration et documentation d'architecture.

Les fondations techniques de Dweve, de Numerus et BitWeave à Lattice et AION. Vérifiez le parcours d'accès de chaque projet avant de commencer.

Une fois qu'un projet est publié, suivez les instructions de son dépôt pour proposer une pull request. Avant cela, la page du projet indique sa période et les conditions expliquent le parcours de révision. Vous pouvez poser des questions à tout moment.

Les modifications acceptées sont fusionnées selon la politique du projet.

Exécutez les vérifications CI documentées par le projet pour cette modification.

Les vérifications documentées s'appliquent.

Traitez les retours et suivez les règles d'approbation du projet.

Ouvrez une pull request lorsque le projet l'accepte, référencez le problème si nécessaire et remplissez son modèle.

Exécutez les tests et les vérifications de qualité documentés par le projet avant d'ouvrir une pull request.

Exécuter les vérifications de qualité localement.

Signez les commits et suivez le format de commit uniquement si le projet l'exige.

Créez une branche selon les instructions de nommage du projet.

Si le projet est public et accepte les modifications, créez un fork comme décrit dans ses instructions.

Chaque étape a une attente claire. Utilisez les vérifications de qualité documentées par le projet.

De la demande d'accès ou du fork à la révision.

Les projets publics peuvent utiliser un workflow fork-and-pull GitHub. Vérifiez les instructions de chaque projet pour les noms de branche, la signature des commits, les références de problèmes, les étapes de révision et les attentes de réponse.

Accès, branche, révision, fusion. Chaque projet documente son parcours.

Suivez les exigences de documentation du projet pour les API publiques, les exemples et les guides plus longs. Ajoutez suffisamment de contexte pour qu'un autre contributeur comprenne et vérifie la modification.

Pour les modifications sensibles aux performances, incluez le contexte de benchmark lorsque le projet le demande. Enregistrez la méthode, la référence, le matériel et le résultat observé afin qu'un réviseur puisse interpréter l'affirmation.

Ajoutez des tests adaptés à la modification et suivez les vérifications du projet pour les tests unitaires, d'intégration, basés sur les propriétés ou par fuzzing. Décrivez toute limitation de couverture ou d'environnement qui affecte la révision.

Tests unitaires, d'intégration et de propriétés.

Portes de qualité documentées pour le projet et la modification.

Une contribution doit être accompagnée de preuves correspondant à la modification. Suivez les tests documentés du projet, les attentes de référence et les exigences de documentation ; ils varient selon le projet et le mode d'accès.

Utilisez les contrôles de test, de référence et de documentation exigés par le projet.

Pour le développement natif, utilisez les dépendances système et les plateformes documentées par le projet. Certains projets fournissent des instructions BUILD.md ; vérifiez-les avant de commencer.

Lorsqu'un projet fournit un workflow conteneurisé, suivez ses instructions Docker ou Podman et utilisez l'image et les commandes qu'il documente. Ne supposez pas que le conteneur correspond à CI sans vérifier le dossier du projet.

Si le projet utilise Rust, installez la chaîne d'outils et les composants nommés dans ses instructions de construction. Des exigences telles que rustfmt, clippy, miri ou une MSRV sont spécifiques au projet.

Moyens de préparer un environnement de développement. Vérifiez les instructions du projet pour le chemin pris en charge.

Chaîne d'outils, conteneurs et configuration native.

Le chemin standard dépend du projet. Lisez ses instructions d'accès et de construction, préparez l'environnement documenté, exécutez les contrôles applicables et utilisez la procédure de révision indiquée.

De nombreux projets Dweve utilisent Rust, mais les chaînes d'outils, les versions minimales, les conteneurs et les cibles d'intégration sont spécifiques au projet. Utilisez la documentation actuelle du projet comme source de vérité.

Chaîne d'outils Rust, Docker et configuration locale là où c'est documenté.

Test du projet, Miri et contrôles de fuzzing

Chaîne d'outils Rust, formatage et contrôles de lint

Dweve maintient quatorze fondations techniques couvrant les mathématiques, l'analyse syntaxique, la récupération, la politique, la simulation et la vérification à l'exécution. HEDL est public sur GitHub ; les autres publient par vagues bimensuelles à partir du 1er septembre 2026, deux à la fois pour commencer. Commencez par la licence de chaque projet et la voie indiquée avant d'envoyer du travail.

Parcourez les pages des fondations. HEDL est public maintenant, AION et Knot publient le 1er septembre 2026, et chaque autre page nomme la vague à laquelle elle appartient. La voie du projet explique comment demander de l'aide.

Construisez une IA souveraine avec nous.

Les contributions acceptées peuvent être créditées dans les notes de version ou un registre des contributeurs lorsque le projet en tient un. Vérifiez les conditions du projet pour toute reconnaissance ou autre avantage.

Reconnaissance dans le registre du projet.

Des sessions de contributeurs peuvent être annoncées lorsqu'un projet les planifie. Consultez la page du projet ou contactez Dweve pour les options de participation actuelles ; le lieu, le calendrier et le support dépendent de l'événement.

Vous pouvez demander des conseils de contribution via le projet ou la voie de contact. La possibilité qu'un mainteneur examine une première modification, la langue disponible et la rapidité de réponse dépendent du projet et de la capacité actuelle.

Les conseils de projet, les sessions communautaires et les registres de contribution dépendent de la voie que vous choisissez.

Conseils, sessions et registres de projet.

Contribuer peut sembler intimidant. Commencez par une question concrète, un rapport, une modification de documentation ou un test. Si un dépôt expose des modèles de problème ou un point d'entrée, utilisez-le ; sinon, demandez la voie actuelle via Dweve. Le support et le temps de réponse dépendent du projet.

Les pratiques de révision dépendent du projet. Lisez ses conditions de contribution pour savoir qui peut examiner une modification, quels contrôles s'appliquent, comment les problèmes de sécurité sont traités et si la discussion est publique.

Révision par les mainteneurs si requise.

Vérifiez la licence et les conditions d'accès aux sources de chaque projet avant d'intégrer ou d'envoyer du travail. Si elles ne sont pas indiquées, contactez Dweve avant toute utilisation.

Conditions de licence et d'accès propres à chaque projet.

Les conditions de contribution varient selon le projet. Consultez le dépôt ou la voie de contact pour connaître la licence applicable, les conditions d'examen et tout accord demandé avant de soumettre.

Les conditions de contribution, la licence et l'examen varient selon le projet.

Conditions de contribution, licence et examen.

La contribution nécessite des conditions claires. Dweve décrit la voie d'accès, de licence et d'examen actuelle pour chaque projet. Les dépôts sont publiés par cycles bimensuels à partir du 1er septembre 2026, alors vérifiez la fiche du projet avant d'investir du temps ou de soumettre un travail.

Conditions claires. Voie documentée. Responsabilité partagée.

Conception d'interfaces, audits d'accessibilité, iconographie et ressources de marque. Les designers peuvent proposer des travaux pour Fabric, le site de documentation et les surfaces de projet. Suivez les directives de marque et d'accessibilité disponibles, et demandez avant de réutiliser des fichiers ou des jetons.

Expérience utilisateur et conception visuelle.

Tests manuels, extension des tests automatisés, tests fuzz et benchmarks. Les testeurs vérifient que les nouvelles versions fonctionnent sur du matériel réel et dans des flux de travail réels. Les testeurs fuzz trouvent des cas limites que la logique déterministe devrait gérer. Les benchmarkeurs valident les affirmations de performance. Cette piste est idéale pour les esprits méthodiques qui aiment casser les choses.

Références API, guides utilisateur, tutoriels et traduction. Les rédacteurs techniques peuvent proposer des améliorations via la voie documentée du projet, et la plupart des tâches de documentation ne nécessitent pas de codage. Consultez le projet pour connaître ses outils et son processus d'examen.

Corrections de bogues, améliorations de performance, nouvelles fonctionnalités et refactorisation. Plusieurs fondations utilisent Rust, avec d'autres langages apparaissant là où le projet en a besoin. Suivez les instructions du projet concernant l'accès au code source, l'examen et les tests ; les points d'entrée publics ne sont pas garantis.