Contribute to Dweve AI Infrastructure

Fuldtidsstillinger inden for engineering og produkt. Remote-first inden for EU.

Spørg om projektets rute, licens og bidragsbetingelser, før du sender arbejde.

Udgivelsesnoter, dybe dyk og ærlige postmortems fra teamet.

API-referencer, integrationsguider og arkitekturdokumentation.

Dweves tekniske fundamenter, fra Numerus og BitWeave til Lattice og AION. Tjek hvert projekts adgangsrute, før du begynder.

Når et projekt er offentliggjort, skal du følge dets repository-instruktioner for at foreslå en pull request. Før det viser projektsiden runden, og vilkårene forklarer review-ruten. Du kan spørge om det på ethvert tidspunkt.

Accepterede ændringer flettes i henhold til projektets politik.

Kør de CI-checks, som projektet dokumenterer for denne ændring.

Håndter feedbacken og følg projektets godkendelsesregler.

Åbn en pull request, når projektet accepterer en, referer til issue, hvis det kræves, og udfyld skabelonen.

Kør de tests og kvalitetschecks, som projektet dokumenterer, før du åbner en pull request.

Signér commits, og følg commit-formatet, kun når projektet kræver det.

Opret en branch i henhold til projektets navngivningsinstruktioner.

Hvis projektet er offentligt og accepterer ændringer, skal du oprette en fork, som dets instruktioner beskriver.

Hvert trin har en klar forventning. Brug de kvalitetschecks, som projektet dokumenterer.

Fra adgangsanmodning eller fork til review.

Offentlige projekter kan bruge en GitHub fork-and-pull-workflow. Tjek hvert projekts instruktioner for branchnavne, commit-signering, issue-referencer, review-trin og forventninger til svar.

Adgang, branch, review, merge. Hvert projekt dokumenterer sin rute.

Følg projektets dokumentationskrav for offentlige API'er, eksempler og længere guides. Tilføj nok kontekst til, at en anden bidragyder kan forstå og tjekke ændringen.

For præstationsfølsomme ændringer skal du inkludere benchmark-kontekst, når projektet beder om det. Registrer metode, baseline, hardware og observeret resultat, så en reviewer kan fortolke påstanden.

Tilføj tests, der passer til ændringen, og følg projektets checks for enheds-, integrations-, property-baserede eller fuzz-tests. Beskriv eventuelle dæknings- eller miljøbegrænsninger, der påvirker reviewet.

Enheds-, integrations- og property-tests.

Kvalitetsporte dokumenteret for projektet og ændringen.

Et bidrag skal medbringe dokumentation, der matcher ændringen. Følg projektets dokumenterede test, benchmark-forventninger og dokumentationskrav; de varierer efter projekt og adgangsvej.

Brug de test-, benchmark- og dokumentationskontroller, som projektet kræver.

Til native udvikling skal du bruge de systemafhængigheder og platforme, som projektet dokumenterer. Nogle projekter har BUILD.md-instruktioner; tjek dem, før du begynder.

Hvis et projekt tilbyder en container-workflow, skal du følge dets Docker- eller Podman-instruktioner og bruge det image og de kommandoer, det dokumenterer. Antag ikke, at containeren matcher CI uden at tjekke projektets registrering.

Hvis projektet bruger Rust, skal du installere værktøjskæden og de komponenter, der er nævnt i dets build-instruktioner. Krav som rustfmt, clippy, miri eller en MSRV er projektspecifikke.

Måder at forberede et udviklingsmiljø på. Tjek projektets instruktioner for den understøttede vej.

Værktøjskæde, containere og native opsætning.

Standardvejen afhænger af projektet. Læs dets adgangs- og build-instruktioner, forbered det dokumenterede miljø, kør de kontroller, der gælder, og brug den angivne review-vej.

Mange Dweve-projekter bruger Rust, men værktøjskæder, minimumsversioner, containere og integrationer er projektspecifikke. Brug den aktuelle projektdokumentation som kilde til sandheden.

Rust-værktøjskæde, Docker og lokal opsætning, hvor det er dokumenteret.

Rust-værktøjskæde, formatering og lint-kontroller

Dweve vedligeholder fjorten tekniske fundamenter, der spænder over matematik, parsing, retrieval, politik, simulering og runtime-verifikation. HEDL er offentligt på GitHub; resten udgives i fjorten-dages runder fra 1. september 2026, to ad gangen til at begynde med. Start med hvert projekts licens og angivne vej, før du sender arbejde.

Gennemse fundament-siderne. HEDL er offentligt nu, AION og Knot udgives den 1. september 2026, og hver anden side angiver, hvilken runde den er i. Projektvejen forklarer, hvordan du beder om hjælp.

Accepterede bidrag kan blive krediteret i release notes eller en bidragyderregistrering, når projektet fører en. Tjek projektets vilkår for eventuel anerkendelse eller anden fordel.

Bidragydersessioner kan blive annonceret, når et projekt planlægger dem. Tjek projektsiden eller kontakt Dweve for aktuelle deltagelsesmuligheder; placering, tidspunkt og support afhænger af arrangementet.

Du kan bede om bidragsvejledning gennem projekt- eller kontaktvejen. Om en maintainer kan gennemgå en første ændring, hvilket sprog der er tilgængeligt, og hvor hurtigt nogen svarer, afhænger af projektet og den aktuelle kapacitet.

Projektvejledning, fællesskabssessioner og bidragsregistre afhænger af den vej, du vælger.

Vejledning, sessioner og projektregistre.

At bidrage kan føles skræmmende. Start med et konkret spørgsmål, en rapport, en dokumentationsændring eller en test. Hvis et repository har issue-skabeloner eller et indgangspunkt, så brug det; ellers anmod om den aktuelle vej gennem Dweve. Support og svartid afhænger af projektet.

Review-praksis afhænger af projektet. Læs dets bidragsvilkår for at se, hvem der kan gennemgå en ændring, hvilke kontroller der gælder, hvordan sikkerhedsproblemer håndteres, og om diskussionen er offentlig.

Tjek licens- og kildeadgangsvilkårene for hvert projekt, før du integrerer eller sender arbejde. Hvis de ikke er angivet, så kontakt Dweve før brug.

Bidragsvilkårene varierer fra projekt til projekt. Tjek repository'et eller kontaktvejen for den gældende licens, gennemgangsbetingelser og eventuel aftale, før du indsender.

Bidragsvilkår, licens og gennemgang varierer fra projekt til projekt.

Bidrag kræver klare vilkår. Dweve beskriver den aktuelle adgangs-, licens- og gennemgangsvej for hvert projekt. Repositories udgives i fjorten dages runder fra 1. september 2026, så tjek projektregistret, før du bruger tid eller indsender arbejde.

Klare vilkår. Dokumenteret vej. Delt ansvar.

Interface-design, tilgængelighedsrevisioner, ikonografi og brandaktiver. Designere kan foreslå arbejde til Fabric, dokumentationssitet og projektoverflader. Følg den tilgængelige brand- og tilgængelighedsvejledning, og spørg, før du genbruger filer eller tokens.

Manuel testning, udvidelse af automatiserede tests, fuzz-testning og benchmarking. Testpersoner verificerer, at nye udgivelser fungerer på rigtig hardware og i rigtige arbejdsgange. Fuzz-testere finder kanttilfælde, som deterministisk logik bør håndtere. Benchmarkere validerer præstationskrav. Dette spor er ideelt for metodiske tænkere, der nyder at bryde ting.

API-referencer, brugervejledninger, tutorials og oversættelse. Tekniske forfattere kan foreslå forbedringer gennem den dokumenterede projektvej, og de fleste dokumentationsopgaver kræver ikke kodning. Tjek projektet for dets værktøjer og gennemgangsproces.

Fejlrettelser, præstationsforbedringer, nye funktioner og refaktorering. Flere fundamenter bruger Rust, med andre sprog, hvor projektet har brug for dem. Følg projektets kildeadgangs-, gennemgangs- og testinstruktioner; offentlige indgangspunkter er ikke garanteret.

Softwareudvikling, dokumentation, kvalitetssikring og design. Den tilgængelige projektvej og kontaktpunkt varierer fra fundament til fundament.

Vi organiserer bidrag i fire brede spor. Hvert fundament beskriver sin tilgængelige vej, omfang og gennemgangsvilkår. Du kan gå til arbejdet som individ, universitetsforskningsgruppe eller ingeniørteam, underlagt projektets adgangsgrænse.

Kode, dokumentation, testning og design. Enhver færdighed har en plads her.

Teams, der bidrager gennem en projekts vej, kan opbygge dybere ekspertise end teams, der kun forbruger det. Ingeniører lærer de interne systemer, de er afhængige af, og kan udvikle relationer med vedligeholdere, når projektet understøtter den kontakt.

Et velafgrænset bidrag kan informere et projekts køreplan, når dets vedligeholdere accepterer det. Organisationer bør behandle bidragstid som arbejde med et klart omfang, gennemgangsvej og adgangsgrænse, ikke som et løfte om produktkontrol.

Projektsynlighed følger udgivelsesplanen. HEDL er offentlig; hvert andet fundament har en offentlig beskrivelse nu og dets repository og dokumentation, når dets runde kommer. Læs hver projektdokumentation og licens, før du beslutter, hvad du kan inspicere, verificere eller genbruge.

Dweve er registreret i Nederlandene og udvikler i Den Europæiske Union. Projektlicenser, styring og datahåndtering beskrives pr. projekt og kan variere. Bidrag etablerer ikke i sig selv regulatorisk overholdelse; tjek de vilkår og beviser, der gælder for din brug.

At bidrage giver dig en måde at undersøge, hvordan et projekt håndterer data, beslutninger og styring. Tjek den vej og de beviser, der gælder.