Contribute to Dweve AI Infrastructure

Vollzeitstellen in den Bereichen Engineering und Produkt. Remote-first innerhalb der EU.

Fragen Sie nach Projektroute, Lizenz und Beitragsbedingungen, bevor Sie Arbeit einsenden.

Release Notes, Deep Dives und ehrliche Postmortems vom Team.

API-Referenzen, Integrationsanleitungen und Architekturdokumentation.

Dweves technische Grundlagen, von Numerus und BitWeave bis Lattice und AION. Prüfen Sie vor Beginn den Zugriffsweg jedes Projekts.

Sobald ein Projekt veröffentlicht wurde, folgen Sie den Repository-Anweisungen, um einen Pull Request vorzuschlagen. Davor enthält die Projektseite die Runde und die Bedingungen erklären den Review-Weg. Sie können jederzeit danach fragen.

Akzeptierte Änderungen werden gemäß der Projektrichtlinie gemerged.

Führen Sie die CI-Checks aus, die das Projekt für diese Änderung dokumentiert.

Gehen Sie auf das Feedback ein und befolgen Sie die Genehmigungsregeln des Projekts.

Öffnen Sie einen Pull Request, wenn das Projekt einen akzeptiert, referenzieren Sie bei Bedarf das Issue und füllen Sie dessen Vorlage aus.

Führen Sie die vom Projekt dokumentierten Tests und Qualitätschecks aus, bevor Sie einen Pull Request öffnen.

Signieren Sie Commits und befolgen Sie das Commit-Format nur, wenn das Projekt es verlangt.

Erstellen Sie einen Branch gemäß den Namensanweisungen des Projekts.

Wenn das Projekt öffentlich ist und Änderungen akzeptiert, erstellen Sie einen Fork, wie in den Anweisungen beschrieben.

Jeder Schritt hat eine klare Erwartung. Nutzen Sie die vom Projekt dokumentierten Qualitätschecks.

Von Zugriffsanfrage oder Fork bis Review.

Öffentliche Projekte können einen GitHub-Fork-and-Pull-Workflow verwenden. Prüfen Sie die Anweisungen jedes Projekts zu Branchnamen, Commit-Signierung, Issue-Referenzen, Review-Schritten und Antwortzeiten.

Zugriff, Branch, Review, Merge. Jedes Projekt dokumentiert seinen Weg.

Befolgen Sie die Dokumentationsanforderungen des Projekts für öffentliche APIs, Beispiele und längere Anleitungen. Fügen Sie genug Kontext hinzu, damit ein anderer Mitwirkender die Änderung versteht und prüfen kann.

Bei leistungssensitiven Änderungen fügen Sie Benchmark-Kontext hinzu, wenn das Projekt danach fragt. Dokumentieren Sie Methode, Baseline, Hardware und beobachtetes Ergebnis, damit ein Reviewer die Aussage interpretieren kann.

Fügen Sie zum Change passende Tests hinzu und befolgen Sie die Projekt-Checks für Unit-, Integrations-, Property-basierte oder Fuzz-Tests. Beschreiben Sie Abdeckungs- oder Umgebungslimits, die den Review beeinflussen.

Unit-, Integrations- und Property-Tests.

Qualitätsgates, die für Projekt und Änderung dokumentiert sind.

Ein Beitrag sollte Nachweise enthalten, die zu seiner Änderung passen. Befolgen Sie die dokumentierten Tests, Benchmark-Erwartungen und Dokumentationsanforderungen des Projekts; diese variieren je nach Projekt und Zugangsweg.

Verwenden Sie die vom Projekt geforderten Test-, Benchmark- und Dokumentationsprüfungen.

Für die native Entwicklung verwenden Sie die vom Projekt dokumentierten Systemabhängigkeiten und Plattformen. Einige Projekte stellen BUILD.md-Anweisungen bereit; prüfen Sie diese, bevor Sie beginnen.

Wenn ein Projekt einen Container-Workflow bereitstellt, befolgen Sie dessen Docker- oder Podman-Anweisungen und verwenden Sie das dokumentierte Image und die dokumentierten Befehle. Gehen Sie nicht davon aus, dass der Container mit CI übereinstimmt, ohne den Projektdatensatz zu prüfen.

Wenn das Projekt Rust verwendet, installieren Sie die Toolchain und Komponenten, die in seinen Build-Anweisungen genannt werden. Anforderungen wie rustfmt, clippy, miri oder eine MSRV sind projektspezifisch.

Möglichkeiten zur Vorbereitung einer Entwicklungsumgebung. Prüfen Sie die Projektanweisungen für den unterstützten Weg.

Toolchain, Container und native Einrichtung.

Der Standardweg hängt vom Projekt ab. Lesen Sie dessen Zugriffs- und Build-Anweisungen, bereiten Sie die dokumentierte Umgebung vor, führen Sie die zutreffenden Prüfungen durch und nutzen Sie den angegebenen Review-Weg.

Viele Dweve-Projekte verwenden Rust, aber Toolchains, Mindestversionen, Container und Integrationsziele sind projektspezifisch. Verwenden Sie die aktuelle Projektdokumentation als Quelle der Wahrheit.

Rust-Toolchain, Docker und lokale Einrichtung, sofern dokumentiert.

Rust-Toolchain, Formatierungs- und Lint-Prüfungen

Lesen Sie den Beitragsleitfaden von HEDL

Dweve pflegt vierzehn technische Grundlagen, die Mathematik, Parsing, Retrieval, Policy, Simulation und Laufzeitverifikation abdecken. HEDL ist öffentlich auf GitHub; die übrigen erscheinen in vierzehntägigen Runden ab dem 1. September 2026, zunächst zwei gleichzeitig. Beginnen Sie mit jeder Projektlizenz und dem angegebenen Weg, bevor Sie Arbeit senden.

Durchsuchen Sie die Grundlagenseiten. HEDL ist jetzt öffentlich, AION und Knot erscheinen am 1. September 2026, und jede andere Seite nennt die Runde, in der sie sich befindet. Der Projektweg erklärt, wie Sie um Hilfe bitten können.

Akzeptierte Beiträge können in Versionshinweisen oder einem Beitragsdatensatz genannt werden, wenn das Projekt einen führt. Prüfen Sie die Projektbedingungen für etwaige Anerkennung oder andere Vorteile.

Beitragssitzungen können angekündigt werden, wenn ein Projekt sie plant. Prüfen Sie die Projektseite oder kontaktieren Sie Dweve für aktuelle Teilnahmemöglichkeiten; Ort, Zeitpunkt und Unterstützung hängen von der Veranstaltung ab.

Sie können über den Projekt- oder Kontaktweg um Beitragsberatung bitten. Ob ein Maintainer eine erste Änderung überprüfen kann, welche Sprache verfügbar ist und wie schnell jemand antwortet, hängt vom Projekt und der aktuellen Kapazität ab.

Projektberatung, Community-Sitzungen und Beitragsdatensätze hängen vom gewählten Weg ab.

Beratung, Sitzungen und Projektdatensätze.

Beitragen kann einschüchternd wirken. Beginnen Sie mit einer konkreten Frage, einem Bericht, einer Dokumentationsänderung oder einem Test. Wenn ein Repository Issue-Vorlagen oder einen Einstiegspunkt bereitstellt, nutzen Sie diese; andernfalls fordern Sie den aktuellen Weg über Dweve an. Unterstützung und Antwortzeit hängen vom Projekt ab.

Review-Praktiken hängen vom Projekt ab. Lesen Sie dessen Beitragsbedingungen, um zu sehen, wer eine Änderung überprüfen kann, welche Prüfungen gelten, wie Sicherheitsbedenken behandelt werden und ob die Diskussion öffentlich ist.

Prüfen Sie die Lizenz- und Quellzugriffsbedingungen für jedes Projekt, bevor Sie integrieren oder Arbeit senden. Wenn sie nicht angegeben sind, kontaktieren Sie Dweve vor der Verwendung.

Lizenz- und Zugriffsbedingungen pro Projekt.

Die Beitragsbedingungen variieren je nach Projekt. Prüfen Sie das Repository oder die Kontaktroute für die geltende Lizenz, die Überprüfungsbedingungen und etwaige Vereinbarungen, bevor Sie etwas einreichen.

Beitragsbedingungen, Lizenz und Überprüfung variieren je nach Projekt.

Beitragsbedingungen, Lizenz und Überprüfung.

Beiträge benötigen klare Bedingungen. Dweve beschreibt den aktuellen Zugriff, die Lizenz und die Überprüfungsroute für jedes Projekt. Repositories werden ab dem 1. September 2026 in vierzehntägigen Runden veröffentlicht. Prüfen Sie daher den Projekteintrag, bevor Sie Zeit investieren oder Arbeiten einreichen.

Klare Bedingungen. Dokumentierte Route. Geteilte Verantwortung.

Interface-Design, Barrierefreiheits-Audits, Ikonografie und Marken-Assets. Designer können Arbeiten für Fabric, die Dokumentationsseite und Projektflächen vorschlagen. Befolgen Sie die verfügbaren Marken- und Barrierefreiheitsrichtlinien und fragen Sie, bevor Sie Dateien oder Tokens wiederverwenden.

Manuelles Testen, Erweiterung automatisierter Tests, Fuzz-Testing und Benchmarking. Tester verifizieren, dass neue Releases auf realer Hardware und in realen Workflows funktionieren. Fuzz-Tester finden Randfälle, die deterministische Logik behandeln sollte. Benchmarker validieren Leistungsaussagen. Dieser Track ist ideal für methodische Denker, die gerne Dinge kaputt machen.

API-Referenzen, Benutzerhandbücher, Tutorials und Übersetzung. Technische Autoren können Verbesserungen über die dokumentierte Projektroute vorschlagen, und die meisten Dokumentationsaufgaben erfordern keine Programmierkenntnisse. Prüfen Sie das Projekt auf seine Werkzeuge und seinen Überprüfungsprozess.

Dokumentation und technisches Schreiben.

Fehlerbehebungen, Leistungsverbesserungen, neue Funktionen und Refactoring. Mehrere Foundations verwenden Rust, wobei andere Sprachen dort auftauchen, wo das Projekt sie benötigt. Befolgen Sie die Anweisungen des Projekts zu Quellzugriff, Überprüfung und Tests; öffentliche Einstiegspunkte sind nicht garantiert.

Softwareentwicklung, Dokumentation, Qualitätssicherung und Design. Die verfügbare Projektroute und der Ansprechpartner variieren je nach Foundation.

Wir organisieren Beiträge in vier breite Tracks. Jede Foundation beschreibt ihre verfügbare Route, ihren Umfang und ihre Überprüfungsbedingungen. Sie können die Arbeit als Einzelperson, universitäre Forschungsgruppe oder Ingenieurteam angehen, vorbehaltlich der Zugriffsgrenze des Projekts.