Bijdragen aan Dweve AI-infrastructuur

Kies de doelgroep die bij je vraag past

De pagina bevat drie selecteerbare lezingen van hetzelfde onderwerp.

Fulltimefuncties in engineering en product. Remote-first binnen de EU.

Vraag voordat je werk instuurt welke projectroute, licentie en voorwaarden voor bijdragen gelden.

Release notes, diepgaande analyses en eerlijke postmortems van het team.

API-referenties, integratiegidsen en architectuurdocumentatie.

De technische fundamenten van Dweve, van Numerus en BitWeave tot Lattice en AION. Controleer de toegangsroute van elk project voordat je begint.

Zodra een project is gepubliceerd, volg je de instructies van de repository om een pull request voor te stellen. Daarvoor vermeldt de projectpagina de ronde en leggen de voorwaarden de reviewroute uit. Je mag altijd vragen stellen.

Geaccepteerde wijzigingen worden volgens het projectbeleid gemergd.

Voer de CI-controles uit die het project voor deze wijziging documenteert.

Verwerk de feedback en volg de goedkeuringsregels van het project.

Open een pull request als het project dat aanneemt, verwijs naar het issue als dat vereist is en vul de template in.

Voer de tests en kwaliteitscontroles uit die het project voorschrijft voordat je een pull request opent.

Onderteken commits en volg het commitformaat alleen als het project dat vereist.

Maak een branch volgens de naamgevingsinstructies van het project.

Maak een fork als het project openbaar is, bijdragen aanneemt en dat in de instructies staat.

Elke stap heeft een duidelijke verwachting. Gebruik de kwaliteitscontroles die het project documenteert.

Van toegangsaanvraag of fork naar review.

Openbare projecten kunnen een GitHub fork-and-pull-workflow gebruiken. Controleer per project de regels voor branchnamen, commitondertekening, issuereferenties, reviews en verwachte reactietijd.

Toegang, branch, review, merge. Elk project beschrijft zijn route.

Volg de documentatie-eisen van het project voor publieke API's, voorbeelden en langere handleidingen. Voeg genoeg context toe zodat een andere bijdrager de wijziging kan begrijpen en controleren.

Voeg bij prestatiegevoelige wijzigingen benchmarkcontext toe als het project dat vraagt. Noteer methode, nulmeting, hardware en waargenomen resultaat, zodat een reviewer de claim kan beoordelen.

Voeg tests toe die bij de wijziging passen en volg de controles van het project voor unit-, integratie-, property-based- of fuzz-tests. Beschrijf beperkingen in dekking of omgeving die voor de review van belang zijn.

Unit-, integratie- en property-based tests.

Kwaliteitspoorten die het project en de wijziging voorschrijven.

Een bijdrage moet bewijs meenemen dat past bij de wijziging. Volg de gedocumenteerde test-, benchmark- en documentatie-eisen van het project; die verschillen per project en toegangsroute.

Gebruik de test-, benchmark- en documentatiecontroles die het project voorschrijft.

Gebruik voor native ontwikkeling de systeemafhankelijkheden en platforms die het project documenteert. Sommige projecten hebben instructies in BUILD.md; controleer die voordat je begint.

Volg de Docker- of Podman-instructies als een project een containerworkflow aanbiedt. Gebruik de image en commando's die het project documenteert; ga niet zonder controle ervan uit dat de container gelijk is aan CI.

Als het project Rust gebruikt, installeer je de toolchain en componenten uit de buildinstructies. Eisen voor rustfmt, clippy, miri of een MSRV zijn projectspecifiek.

Manieren om je ontwikkelomgeving voor te bereiden. Controleer in de projectinstructies welke route wordt ondersteund.

Toolchain, containers en native installatie.

De standaardroute verschilt per project. Lees de toegangs- en buildinstructies, bereid de gedocumenteerde omgeving voor, voer de relevante controles uit en gebruik de aangegeven reviewroute.

Veel Dweve-projecten gebruiken Rust, maar toolchains, minimumversies, containers en integratietargets zijn projectspecifiek. Gebruik de actuele projectdocumentatie als bron van waarheid.

Rust-toolchain, Docker en lokale installatie waar gedocumenteerd.

Tests, Miri en fuzzcontroles van het project

Rust-toolchain, formattering en lintcontroles

Dweve onderhoudt veertien technische fundamenten op het gebied van wiskunde, parsing, retrieval, beleid, simulatie en runtimeverificatie. HEDL is publiek op GitHub; de rest verschijnt in tweewekelijkse rondes vanaf 1 oktober 2026, om te beginnen twee tegelijk. Begin bij de licentie en de vermelde route van elk project voordat je werk instuurt.

Bekijk de fundamentpaginas. HEDL is nu publiek, AION en Knot verschijnen respectievelijk op 15 oktober 2026 en 1 oktober 2026, en elke andere pagina noemt de ronde waarin het project zit. De projectroute legt uit hoe je hulp vraagt.

Geaccepteerde bijdragen kunnen in releasenotes of een bijdragersregister worden vermeld als het project zo'n register bijhoudt. Controleer de projectvoorwaarden voor erkenning of andere voordelen.

Bijdragersessies worden aangekondigd wanneer een project ze plant. Vraag op de projectpagina of bij Dweve naar de actuele mogelijkheden; locatie, timing en ondersteuning verschillen per evenement.

Je kunt via de project- of contactroute om begeleiding vragen. Of een maintainer een eerste wijziging kan bekijken, welke taal beschikbaar is en hoe snel iemand reageert, hangt af van het project en de actuele capaciteit.

Projectbegeleiding, communitysessies en bijdragersregisters verschillen per route.

Begeleiding, sessies en projectdossiers.

Bijdragen kan intimiderend voelen. Begin met een concrete vraag, melding, documentatiewijziging of test. Als een repository templates of een instappunt heeft, gebruik die dan; anders vraag je de actuele route aan bij Dweve. Ondersteuning en reactietijd verschillen per project.

Reviewpraktijken verschillen per project. Lees de bijdragerichtlijnen om te zien wie een wijziging kan beoordelen, welke controles gelden, hoe beveiligingskwesties worden behandeld en of de bespreking openbaar is.

Controleer de licentie en broncodetoegang van elk project voordat je integreert of werk instuurt. Als die voorwaarden niet zijn vermeld, neem dan vóór gebruik contact op met Dweve.

Voorwaarden voor bijdragen verschillen per project. Controleer via de repository of contactroute welke licentie, reviewvoorwaarden en eventuele overeenkomst vóór indiening gelden.

Licentie, review en voorwaarden verschillen per project.

Bijdragen vraagt om heldere voorwaarden. Dweve beschrijft per project de huidige toegang, licentie en reviewroute. Repositories verschijnen in tweewekelijkse rondes vanaf 1 oktober 2026, dus bekijk het projectrecord voordat je tijd investeert of werk instuurt.

Duidelijke voorwaarden. Gedocumenteerde route. Gedeelde verantwoordelijkheid.

Interfaceontwerp, toegankelijkheidsaudits, iconografie en merkmiddelen. Ontwerpers kunnen werk voorstellen voor Fabric, de documentatiesite en projectoppervlakken. Volg de beschikbare richtlijnen voor merk en toegankelijkheid en vraag toestemming voordat je bestanden of tokens hergebruikt.

Handmatig testen, uitbreiding van geautomatiseerde tests, fuzzentests en benchmarken. Testers verifiëren dat nieuwe releases werken op echte hardware en in echte workflows. Fuzzentesters vinden randgevallen die deterministische logica zou moeten afhandelen. Benchmarkers toetsen prestatieclaims. Deze track is ideaal voor methodische denkers die graag dingen breken.

API-referenties, gebruikershandleidingen, tutorials en vertalingen. Technische schrijvers kunnen verbeteringen voorstellen via de gedocumenteerde projectroute; voor de meeste documentatietaken is geen programmeerkennis nodig. Controleer per project welke tools en reviewroute gelden.

Bugfixes, prestatieverbeteringen, nieuwe functies en refactoring. Verschillende fundamenten gebruiken Rust, naast andere talen waar het project dat nodig heeft. Volg de instructies voor broncodetoegang, review en testen; openbare instappunten zijn niet gegarandeerd.

Software-engineering, documentatie, kwaliteitsborging en ontwerp. De projectroute en het aanspreekpunt verschillen per fundament.

We organiseren bijdragen in vier brede tracks. Elk fundament beschrijft de beschikbare route, scope en reviewvoorwaarden. Je kunt het werk benaderen als individu, universitaire onderzoeksgroep of engineeringteam, binnen de toegangsgrens van het project.

Code, docs, testen en ontwerp. Elke vaardigheid heeft hier een plek.

Teams die via de route van een project bijdragen, kunnen diepere expertise opbouwen dan teams die het alleen gebruiken. Engineers leren de interne werking van systemen kennen en kunnen relaties met maintainers ontwikkelen als het project dat contact ondersteunt.

Een goed afgebakende bijdrage kan de roadmap van een project beïnvloeden als maintainers het werk accepteren. Behandel bijdragetijd als werk met een duidelijke scope, reviewroute en toegangsgrens, niet als een belofte van productcontrole.

De zichtbaarheid van een project volgt het releaseschema. HEDL is publiek; elk ander fundament heeft nu een publieke beschrijving en krijgt zijn repository en documentatie wanneer zijn ronde aan de beurt is. Lees de documentatie en licentie van elk project voordat je bepaalt wat je kunt inspecteren, verifieren of hergebruiken.