Contribute to Dweve AI Infrastructure

Heltidstjänster inom teknik och produkt. Remote-first inom EU.

Fråga vilken projektväg, licens och bidragsvillkor som gäller innan du skickar arbete.

Release notes, djupdykningar och ärliga postmortems från teamet.

API-referenser, integrationsguider och arkitekturdokumentation.

Dweves tekniska grunder, från Numerus och BitWeave till Lattice och AION. Kontrollera varje projekts åtkomstväg innan du börjar.

När ett projekt har publicerats, följ dess repositories instruktioner för att föreslå en pull request. Innan dess anger projektsidan dess runda och villkoren förklarar granskningsvägen. Du kan fråga om det när som helst.

Godkända ändringar slås samman enligt projektets policy.

Kör de CI-kontroller som projektet dokumenterar för denna ändring.

Åtgärda feedbacken och följ projektets godkännanderegler.

Öppna en pull request när projektet accepterar en, referera till ärendet om det krävs, och fyll i dess mall.

Kör testerna och kvalitetskontrollerna som projektet dokumenterar innan du öppnar en pull request.

Signera commits och följ commit-formatet endast när projektet kräver det.

Skapa en branch enligt projektets namngivningsinstruktioner.

Om projektet är offentligt och accepterar ändringar, skapa en fork som dess instruktioner beskriver.

Varje steg har en tydlig förväntan. Använd de kvalitetskontroller som projektet dokumenterar.

Från åtkomstförfrågan eller fork till granskning.

Offentliga projekt kan använda ett GitHub fork-and-pull-arbetsflöde. Kontrollera varje projekts instruktioner för branchnamn, commit-signering, ärendereferenser, granskningssteg och svarsförväntningar.

Åtkomst, branch, granskning, merge. Varje projekt dokumenterar sin väg.

Följ projektets dokumentationskrav för offentliga API:er, exempel och längre guider. Lägg till tillräckligt med sammanhang för att en annan bidragsgivare ska kunna förstå och kontrollera ändringen.

För prestandakänsliga ändringar, inkludera benchmark-kontext när projektet efterfrågar det. Dokumentera metod, baslinje, hårdvara och observerat resultat så att en granskare kan tolka påståendet.

Lägg till tester som passar ändringen och följ projektets kontroller för enhets-, integrations-, property-baserade eller fuzz-tester. Beskriv eventuella täcknings- eller miljöbegränsningar som påverkar granskningen.

Enhets-, integrations- och property-tester.

Kvalitetsgrindar dokumenterade för projektet och ändringen.

Ett bidrag bör medföra bevis som matchar ändringen. Följ projektets dokumenterade tester, benchmarkförväntningar och dokumentationskrav; de varierar mellan projekt och åtkomstväg.

Använd de tester, benchmarkar och dokumentationskontroller som projektet kräver.

För inbyggd utveckling, använd de systemberoenden och plattformar som projektet dokumenterar. Vissa projekt har BUILD.md-instruktioner; kontrollera dem innan du börjar.

Där ett projekt tillhandahåller ett containerarbetsflöde, följ dess Docker- eller Podman-instruktioner och använd den bild och de kommandon som det dokumenterar. Anta inte att containern matchar CI utan att kontrollera projektets dokumentation.

Om projektet använder Rust, installera verktygskedjan och komponenterna som anges i dess bygginstruktioner. Krav som rustfmt, clippy, miri eller en MSRV är projektspecifika.

Sätt att förbereda en utvecklingsmiljö. Kontrollera projektets instruktioner för den väg som stöds.

Verktygskedja, containrar och inbyggd installation.

Standardvägen beror på projektet. Läs dess åtkomst- och bygginstruktioner, förbered den dokumenterade miljön, kör de kontroller som gäller och använd den angivna granskningsvägen.

Många Dweve-projekt använder Rust, men verktygskedjor, minimiversioner, containrar och integrationsmål är projektspecifika. Använd den aktuella projektdokumentationen som källa till sanning.

Rust-verktygskedja, Docker och lokal installation där det dokumenteras.

Rust-verktygskedja, formatering och lintkontroller

Dweve underhåller fjorton tekniska fundament som spänner över matematik, parsning, hämtning, policy, simulering och runtime-verifiering. HEDL är offentligt på GitHub; resten publiceras i fjorton dagars omgångar från 1 september 2026, två åt gången till att börja med. Börja med varje projekts licens och angivna väg innan du skickar arbete.

Bläddra i fundamentens sidor. HEDL är offentligt nu, AION och Knot publiceras den 1 september 2026, och varje annan sida anger vilken omgång den ingår i. Projektvägen förklarar hur du ber om hjälp.

Godkända bidrag kan krediteras i versionsfakta eller en bidragspost när projektet har en sådan. Kontrollera projektets villkor för eventuellt erkännande eller annan förmån.

Bidragssessioner kan meddelas när ett projekt schemalägger dem. Kontrollera projektsidan eller kontakta Dweve för aktuella deltagandealternativ; plats, tidpunkt och stöd beror på evenemanget.

Du kan be om bidragsvägledning via projekt- eller kontaktvägen. Huruvida en underhållare kan granska en första ändring, vilket språk som finns tillgängligt och hur snabbt någon svarar beror på projektet och aktuell kapacitet.

Projektvägledning, communitysessioner och bidragsposter beror på vilken väg du väljer.

Vägledning, sessioner och projektposter.

Att bidra kan kännas skrämmande. Börja med en konkret fråga, rapport, dokumentationsändring eller ett test. Där ett arkiv exponerar issue-mallar eller en ingångspunkt, använd den; annars begär den aktuella vägen genom Dweve. Stöd och svarstid beror på projektet.

Granskningspraxis beror på projektet. Läs dess bidragsvillkor för att se vem som kan granska en ändring, vilka kontroller som gäller, hur säkerhetsfrågor hanteras och om diskussionen är offentlig.

Kontrollera licens- och källåtkomstvillkoren för varje projekt innan du integrerar eller skickar arbete. Om de inte anges, kontakta Dweve innan användning.

Bidragsvillkoren varierar mellan projekt. Kontrollera arkivet eller kontaktvägen för tillämplig licens, granskningsvillkor och eventuella avtal som krävs innan du skickar in bidrag.

Bidragsvillkor, licens och granskning varierar mellan projekt.

Bidrag kräver tydliga villkor. Dweve beskriver aktuell åtkomst, licens och granskningsväg för varje projekt. Arkiv publiceras i fjorton dagars omgångar från 1 september 2026, så kontrollera projektposten innan du lägger ner tid eller skickar in arbete.

Tydliga villkor. Dokumenterad väg. Delat ansvar.

Gränssnittsdesign, tillgänglighetsgranskningar, ikonografi och varumärkesmaterial. Designers kan föreslå arbete för Fabric, dokumentationswebbplatsen och projektytor. Följ tillgänglig varumärkes- och tillgänglighetsvägledning och fråga innan du återanvänder filer eller tokens.

Manuell testning, utökad automatiserad testning, fuzztestning och prestandamätning. Testare verifierar att nya utgåvor fungerar på riktig hårdvara och i verkliga arbetsflöden. Fuzztestare hittar gränsfall som deterministisk logik bör hantera. Prestandamätare validerar prestandapåståenden. Detta spår passar metodiska tänkare som gillar att bryta saker.

API-referenser, användarhandböcker, handledningar och översättning. Tekniska skribenter kan föreslå förbättringar via den dokumenterade projektvägen, och de flesta dokumentationsuppgifter kräver inte kodning. Kontrollera projektets verktyg och granskningsprocess.

Bugfixar, prestandaförbättringar, nya funktioner och refaktorering. Flera stiftelser använder Rust, med andra språk där projektet behöver dem. Följ projektets instruktioner för källåtkomst, granskning och testning; offentliga ingångspunkter är inte garanterade.

Mjukvaruutveckling, dokumentation, kvalitetssäkring och design. Tillgänglig projektväg och kontaktpunkt varierar mellan stiftelser.

Vi organiserar bidrag i fyra breda spår. Varje stiftelse beskriver sin tillgängliga väg, omfattning och granskningsvillkor. Du kan närma dig arbetet som individ, forskningsgrupp eller ingenjörsteam, beroende på projektets åtkomstgräns.

Kod, dokumentation, testning och design. Varje färdighet har en plats här.

Team som bidrar genom en projekts väg kan bygga djupare expertis än team som bara konsumerar det. Ingenjörer lär sig internerna i system de är beroende av och kan utveckla relationer med underhållare när projektet stödjer den kontakten.

Ett väldefinierat bidrag kan informera ett projekts färdplan när dess underhållare accepterar det. Organisationer bör behandla bidragstid som arbete med tydlig omfattning, granskningsväg och åtkomstgräns, inte som ett löfte om produktkontroll.

Projektsynlighet följer releaseschemat. HEDL är offentlig; varje annan stiftelse har en offentlig beskrivning nu och dess arkiv och dokumentation när dess omgång kommer. Läs varje projekts dokumentation och licens innan du bestämmer vad du kan inspektera, verifiera eller återanvända.

Dweve är registrerat i Nederländerna och utvecklas inom Europeiska unionen. Projektlicenser, styrning och datahantering beskrivs per projekt och kan skilja sig åt. Att bidra etablerar inte i sig regelefterlevnad; kontrollera villkoren och bevisen som gäller för din användning.

Att bidra ger dig ett sätt att undersöka hur ett projekt hanterar data, beslut och styrning. Kontrollera vägen och bevisen som gäller.