Contribute to Dweve AI Infrastructure

Viso etato pareigybės inžinerijos ir produktų srityse. Pirmenybė darbui nuotoliu ES ribose.

Prieš siųsdami darbą, pasiteiraukite, koks projekto kelias, licencija ir įnašų sąlygos.

Leidimų pastabos, išsamios analizės ir nuoširdūs komandos įvykių aptarimai.

API nuorodos, integracijos vadovai ir architektūros dokumentacija.

„Dweve“ techniniai pagrindai: nuo „Numerus“ ir „BitWeave“ iki „Lattice“ ir „AION“. Prieš pradėdami patikrinkite kiekvieno projekto prieigos kelią.

Kai projektas publikuojamas, vadovaukitės jo saugyklos instrukcijomis, kad pateiktumėte pull request. Iki tol projekto puslapyje nurodomas jo raundas, o sąlygose aprašomas peržiūros kelias. Galite klausti apie tai bet kada.

Priimti pakeitimai sujungiami pagal projekto politiką.

Paleiskite CI patikras, kurias projektas dokumentuoja šiam pakeitimui.

Atsižvelkite į atsiliepimus ir laikykitės projekto patvirtinimo taisyklių.

Atidarykite pull request, kai projektas jį priima, jei reikia, nurodykite problemą ir užpildykite jo šabloną.

Prieš atidarydami pull request, paleiskite projekto dokumentuotus testus ir kokybės patikras.

Pasirašykite įsipareigojimus ir laikykitės įsipareigojimų formato tik tada, kai to reikalauja projektas.

Laikykitės projekto įsipareigojimų taisyklių.

Sukurkite šaką pagal projekto pavadinimo instrukcijas.

Jei projektas yra viešas ir priima pakeitimus, sukurkite fork, kaip aprašyta jo instrukcijose.

Kiekvienas žingsnis turi aiškų lūkestį. Naudokite projekto dokumentuotas kokybės patikras.

Nuo prieigos užklausos arba fork iki peržiūros.

Vieši projektai gali naudoti GitHub fork-and-pull darbo eigą. Patikrinkite kiekvieno projekto instrukcijas dėl šakų pavadinimų, įsipareigojimų pasirašymo, problemų nuorodų, peržiūros žingsnių ir atsakymų lūkesčių.

Prieiga, šaka, peržiūra, sujungimas. Kiekvienas projektas dokumentuoja savo kelią.

Laikykitės projekto dokumentacijos reikalavimų viešoms API, pavyzdžiams ir ilgesniems vadovams. Pridėkite pakankamai konteksto, kad kitas bendradarbis galėtų suprasti ir patikrinti pakeitimą.

Atliekant našumui jautrius pakeitimus, įtraukite etalonų kontekstą, kai projekto to prašoma. Užfiksuokite metodą, pradinį lygį, aparatinę įrangą ir pastebėtą rezultatą, kad recenzentas galėtų interpretuoti teiginį.

Pridėkite pakeitimui tinkamus testus ir laikykitės projekto patikrų, susijusių su vienetų, integracijos, savybių ar fuzz testavimu. Apibūdinkite visus aprėpties ar aplinkos apribojimus, turinčius įtakos peržiūrai.

Vienetų, integracijos ir savybių testai.

Kokybės vartai, dokumentuoti projektui ir pakeitimui.

Įnašas turėtų turėti įrodymų, atitinkančių jo pakeitimą. Laikykitės projekto dokumentuotų testų, etalonų lūkesčių ir dokumentacijos reikalavimų; jie skiriasi priklausomai nuo projekto ir prieigos būdo.

Naudokite projekto reikalaujamus testavimo, etalonų ir dokumentacijos patikras.

Vietinei kūrybai naudokite sistemos priklausomybes ir platformas, kurias dokumentavo projektas. Kai kurie projektai pateikia BUILD.md instrukcijas; prieš pradėdami jas patikrinkite.

Kai projektas pateikia konteinerių darbo eigą, vadovaukitės jo Docker ar Podman instrukcijomis ir naudokite vaizdą bei komandas, kurias jis dokumentuoja. Nelaikykite, kad konteineris atitinka CI, nepatikrinę projekto įrašo.

Jei projektas naudoja Rust, įdiekite įrankių grandinę ir komponentus, įvardytus jo kūrimo instrukcijose. Reikalavimai, tokie kaip rustfmt, clippy, miri ar MSRV, yra būdingi projektui.

Būdai paruošti kūrimo aplinką. Patikrinkite projekto instrukcijas dėl palaikomo kelio.

Įrankių grandinės, konteineriai ir vietinė sąranka.

Standartinis kelias priklauso nuo projekto. Perskaitykite jo prieigos ir kūrimo instrukcijas, paruoškite dokumentuotą aplinką, atlikite taikomas patikras ir naudokite nurodytą peržiūros kelią.

Daugelis Dweve projektų naudoja Rust, tačiau įrankių grandinės, minimalios versijos, konteineriai ir integracijos tikslai yra būdingi projektui. Naudokite dabartinę projekto dokumentaciją kaip tiesos šaltinį.

Rust įrankių grandinė, Docker ir vietinė sąranka, kur dokumentuota.

Rust įrankių grandinė, formatavimo ir lint patikros

Dweve prižiūri keturiolika techninių pagrindų, apimančių matematiką, analizę, paiešką, politiką, simuliaciją ir vykdymo patikrą. HEDL yra viešas GitHub; likusieji skelbiami kas dvi savaites nuo 2026 m. rugsėjo 1 d., pradžioje po du. Pradėkite nuo kiekvieno projekto licencijos ir nurodyto kelio prieš siųsdami darbą.

Naršykite pagrindų puslapius. HEDL yra viešas dabar, AION ir Knot skelbiami 2026 m. rugsėjo 1 d., o kiekvienas kitas puslapis įvardija ratą, kuriame jis yra. Projekto kelias paaiškina, kaip prašyti pagalbos.

Priimti įnašai gali būti paminėti leidimo pastabose arba įnašų įraše, kai projektas jį veda. Patikrinkite projekto sąlygas dėl bet kokio pripažinimo ar kitos naudos.

Įnašų sesijos gali būti skelbiamos, kai projektas jas suplanuoja. Patikrinkite projekto puslapį arba susisiekite su Dweve dėl dabartinių dalyvavimo galimybių; vieta, laikas ir palaikymas priklauso nuo renginio.

Galite prašyti įnašų gairių per projekto arba kontaktų kelią. Ar prižiūrėtojas gali peržiūrėti pirmąjį pakeitimą, kokia kalba prieinama ir kaip greitai kas nors atsako, priklauso nuo projekto ir dabartinio pajėgumo.

Projekto gairės, bendruomenės sesijos ir įnašų įrašai priklauso nuo pasirinkto kelio.

Įnašas gali atrodyti bauginantis. Pradėkite nuo konkretaus klausimo, ataskaitos, dokumentacijos pakeitimo ar testo. Jei saugykla pateikia problemų šablonus ar įėjimo tašką, naudokite jį; kitaip prašykite dabartinio kelio per Dweve. Palaikymas ir atsakymo laikas priklauso nuo projekto.

Peržiūros praktika priklauso nuo projekto. Perskaitykite jo įnašų sąlygas, kad sužinotumėte, kas gali peržiūrėti pakeitimą, kokios patikros taikomos, kaip sprendžiami saugumo klausimai ir ar diskusija yra vieša.

Patikrinkite kiekvieno projekto licenciją ir prieigos prie šaltinio sąlygas prieš integruodami ar siųsdami darbą. Jei jos nenurodytos, susisiekite su Dweve prieš naudojimą.

Projekto licencijos ir prieigos sąlygos.

Įnašo sąlygos skiriasi priklausomai nuo projekto. Prieš teikdami darbą, patikrinkite saugyklą arba kontaktų kelią dėl taikomos licencijos, peržiūros sąlygų ir bet kokio prašomo susitarimo.

Įnašo sąlygos, licencija ir peržiūra skiriasi priklausomai nuo projekto.

Įnašui reikia aiškių sąlygų. Dweve aprašo dabartinį prieigos, licencijos ir peržiūros kelią kiekvienam projektui. Saugyklos skelbiamos kas dvi savaites nuo 2026 m. rugsėjo 1 d., todėl prieš skirdami laiko ar teikdami darbą patikrinkite projekto įrašą.

Aiškios sąlygos. Dokumentuotas kelias. Bendra atsakomybė.

Sąsajos dizainas, prieinamumo auditai, ikonografija ir prekės ženklo ištekliai. Dizaineriai gali siūlyti darbus Fabric, dokumentacijos svetainei ir projekto paviršiams. Laikykitės turimų prekės ženklo ir prieinamumo gairių ir paklauskite prieš naudodami failus ar žetonus.

Vartotojo patirtis ir vizualinis dizainas.

Rankinis testavimas, automatizuotų testų plėtra, fuzz testavimas ir lyginamoji analizė. Testuotojai patikrina, kad naujos versijos veiktų tikroje įrangoje ir realiuose darbo srautuose. Fuzz testuotojai randa kraštinius atvejus, kuriuos deterministinė logika turėtų apdoroti. Lyginamosios analizės specialistai patvirtina našumo teiginius. Šis takelis idealus metodiškiems mąstytojams, mėgstantiems laužyti dalykus.

API nuorodos, vartotojo vadovai, mokymo programos ir vertimas. Techniniai rašytojai gali siūlyti patobulinimus per dokumentuotą projekto kelią, o daugumai dokumentacijos užduočių nereikia programavimo. Patikrinkite projekto įrankius ir peržiūros procesą.

Klaidų taisymas, našumo patobulinimai, naujos funkcijos ir refaktorinimas. Kelios bazės naudoja Rust, o kitos kalbos atsiranda ten, kur projektui jų reikia. Laikykitės projekto šaltinio prieigos, peržiūros ir testavimo instrukcijų; viešos įėjimo vietos negarantuojamos.

Programinės įrangos inžinerija, dokumentacija, kokybės užtikrinimas ir dizainas. Galimas projekto kelias ir kontaktinis asmuo skiriasi priklausomai nuo bazės.

Įnašą organizuojame į keturis plačius takelius. Kiekviena bazė aprašo savo galimą kelią, apimtį ir peržiūros sąlygas. Galite dirbti kaip asmuo, universitetinė tyrimų grupė ar inžinerijos komanda, laikydamiesi projekto prieigos ribos.

Kodas, dokumentacija, testavimas ir dizainas. Kiekvienam įgūdžiui čia yra vieta.

Komandos, kurios prisideda per projekto kelią, gali įgyti gilesnės patirties nei komandos, kurios tik naudoja. Inžinieriai mokosi sistemų, nuo kurių priklauso, vidaus ir gali užmegzti ryšius su prižiūrėtojais, kai projektas palaiko tokį kontaktą.

Gerai apibrėžtas įnašas gali paveikti projekto kelių žemėlapį, kai jo prižiūrėtojai jį priima. Organizacijos turėtų vertinti įnašo laiką kaip darbą su aiškia apimtimi, peržiūros keliu ir prieigos riba, o ne kaip produkto kontrolės pažadą.

Projekto matomumas atitinka išleidimo grafiką. HEDL yra viešas; kiekviena kita bazė dabar turi viešą aprašymą, o jos saugykla ir dokumentacija atsiras, kai ateis jos eilė. Perskaitykite kiekvieno projekto dokumentaciją ir licenciją prieš nuspręsdami, ką galite apžiūrėti, patikrinti ar naudoti.