Contribute to Dweve AI Infrastructure

Pracovní pozice na plný úvazek v oblasti inženýrství a produktu. Primárně remote v rámci EU.

Než pošlete práci, zeptejte se, která projektová cesta, licence a podmínky příspěvků se vás týkají.

Poznámky k vydáním, podrobné analýzy a upřímné retrospektivy od týmu.

API reference, integrační příručky a dokumentace architektury.

Technické základy Dweve, od Numerus a BitWeave po Lattice a AION. Než začnete, zkontrolujte způsob přístupu ke každému projektu.

Jakmile projekt zveřejní, postupujte podle pokynů v jeho repozitáři a navrhněte pull request. Před tím je na stránce projektu uvedeno jeho kolo a podmínky vysvětlují postup recenze. Můžete se na to kdykoli zeptat.

Přijaté změny se slučují podle politiky projektu.

Spusťte CI kontroly, které projekt pro tuto změnu dokumentuje.

Vypořádejte se se zpětnou vazbou a dodržujte pravidla schvalování projektu.

Otevřete pull request, pokud ho projekt přijímá, v případě potřeby uveďte issue a vyplňte jeho šablonu.

Před otevřením pull requestu spusťte testy a kontroly kvality, které projekt dokumentuje.

Podepisujte commity a dodržujte formát commitů pouze tehdy, pokud to projekt vyžaduje.

Dodržujte pravidla projektu pro commity.

Vytvořte větev podle pokynů projektu pro pojmenování.

Pokud je projekt veřejný a přijímá změny, vytvořte fork podle jeho pokynů.

Každý krok má jasné očekávání. Používejte kontroly kvality, které projekt dokumentuje.

Od žádosti o přístup nebo forku po recenzi.

Veřejné projekty mohou používat GitHub fork-and-pull pracovní postup. U každého projektu si zkontrolujte pokyny pro názvy větví, podepisování commitů, odkazy na issue, kroky recenze a očekávání ohledně odpovědí.

Přístup, větev, recenze, sloučení. Každý projekt dokumentuje svou cestu.

Dodržujte požadavky projektu na dokumentaci pro veřejná API, příklady a delší průvodce. Přidejte dostatek kontextu, aby další přispěvatel mohl změnu pochopit a zkontrolovat.

U změn citlivých na výkon zahrňte kontext benchmarků, pokud o to projekt žádá. Zaznamenejte metodu, baseline, hardware a pozorovaný výsledek, aby recenzent mohl tvrzení interpretovat.

Přidejte testy odpovídající změně a dodržujte kontroly projektu pro unit, integrační, property-based nebo fuzz testování. Popište případná omezení pokrytí nebo prostředí, která ovlivňují recenzi.

Kvalitativní brány dokumentované pro projekt a změnu.

Příspěvek by měl nést důkazy odpovídající jeho změně. Postupujte podle zdokumentovaných testů projektu, očekávání benchmarků a požadavků na dokumentaci; liší se podle projektu a způsobu přístupu.

Použijte testovací, benchmarkové a dokumentační kontroly, které projekt vyžaduje.

Pro nativní vývoj použijte systémové závislosti a platformy zdokumentované projektem. Některé projekty poskytují pokyny BUILD.md; zkontrolujte je, než začnete.

Pokud projekt poskytuje kontejnerový pracovní postup, postupujte podle jeho pokynů pro Docker nebo Podman a použijte obraz a příkazy, které dokumentuje. Nepředpokládejte, že kontejner odpovídá CI, aniž byste zkontrolovali záznam projektu.

Pokud projekt používá Rust, nainstalujte nástrojový řetězec a komponenty uvedené v jeho pokynech pro sestavení. Požadavky jako rustfmt, clippy, miri nebo MSRV jsou specifické pro projekt.

Způsoby přípravy vývojového prostředí. Zkontrolujte pokyny projektu pro podporovanou cestu.

Nástrojový řetězec, kontejnery a nativní nastavení.

Standardní cesta závisí na projektu. Přečtěte si jeho pokyny pro přístup a sestavení, připravte zdokumentované prostředí, spusťte kontroly, které se vztahují, a použijte uvedenou cestu pro recenzi.

Mnoho projektů Dweve používá Rust, ale nástrojové řetězce, minimální verze, kontejnery a integrační cíle jsou specifické pro projekt. Použijte aktuální dokumentaci projektu jako zdroj pravdy.

Rust toolchain, Docker a lokální nastavení, pokud je zdokumentováno.

Rust toolchain, formátování a lint kontroly

Přečtěte si průvodce přispíváním do HEDL

Dweve udržuje čtrnáct technických základů zahrnujících matematiku, parsování, vyhledávání, politiku, simulaci a runtime verifikaci. HEDL je veřejný na GitHubu; ostatní vycházejí ve čtrnáctidenních kolech od 1. září 2026, nejprve vždy dva. Začněte s licencí každého projektu a uvedenou cestou, než pošlete práci.

Procházejte stránky základů. HEDL je nyní veřejný, AION a Knot vycházejí 1. září 2026 a každá další stránka uvádí kolo, ve kterém je. Cesta projektu vysvětluje, jak požádat o pomoc.

Přijaté příspěvky mohou být uvedeny v poznámkách k vydání nebo v záznamu přispěvatelů, pokud si je projekt vede. Zkontrolujte podmínky projektu pro případné uznání nebo jiné výhody.

Sessions pro přispěvatele mohou být oznámeny, když je projekt naplánuje. Zkontrolujte stránku projektu nebo kontaktujte Dweve pro aktuální možnosti účasti; místo, načasování a podpora závisí na události.

Můžete požádat o pokyny k přispívání prostřednictvím projektu nebo kontaktní cesty. Zda správce může zkontrolovat první změnu, který jazyk je k dispozici a jak rychle někdo odpoví, závisí na projektu a aktuální kapacitě.

Pokyny projektu, komunitní sessions a záznamy o příspěvcích závisí na zvolené cestě.

Přispívání může být zastrašující. Začněte s konkrétní otázkou, hlášením, změnou dokumentace nebo testem. Pokud úložiště vystavuje šablony problémů nebo vstupní bod, použijte je; jinak vyžádejte aktuální cestu prostřednictvím Dweve. Podpora a doba odezvy závisí na projektu.

Postupy recenzí závisí na projektu. Přečtěte si jeho podmínky pro přispívání, abyste zjistili, kdo může změnu zkontrolovat, které kontroly platí, jak jsou řešeny bezpečnostní obavy a zda je diskuse veřejná.

Zkontrolujte licenci a podmínky přístupu ke zdrojům pro každý projekt před integrací nebo odesláním práce. Pokud nejsou uvedeny, kontaktujte Dweve před použitím.

Licenční a přístupové podmínky pro jednotlivé projekty.

Podmínky příspěvků se liší podle projektu. Před odesláním příspěvku si ověřte v repozitáři nebo na kontaktní trase příslušnou licenci, podmínky posouzení a případnou dohodu.

Podmínky příspěvků, licence a posouzení se liší podle projektu.

Podmínky příspěvků, licence a posouzení.

Příspěvky potřebují jasné podmínky. Dweve popisuje aktuální přístup, licenci a trasu posouzení pro každý projekt. Repozitáře se zveřejňují ve čtrnáctidenních cyklech od 1. září 2026, proto si před tím, než investujete čas nebo odešlete práci, zkontrolujte záznam projektu.

Jasné podmínky. Dokumentovaná trasa. Sdílená odpovědnost.

Návrh rozhraní, audity přístupnosti, ikonografie a značkové materiály. Designéři mohou navrhovat práci pro Fabric, dokumentační web a povrchy projektů. Řiďte se dostupnými pokyny pro značku a přístupnost a před použitím souborů nebo tokenů se zeptejte.

Uživatelská zkušenost a vizuální design.

Ruční testování, rozšiřování automatizovaných testů, fuzz testování a benchmarky. Testeři ověřují, že nové verze fungují na skutečném hardwaru a v reálných pracovních postupech. Fuzz testeři nacházejí okrajové případy, které by deterministická logika měla zvládnout. Benchmarkeři ověřují výkonnostní tvrzení. Tato trasa je ideální pro metodické myslitele, kteří rádi rozbíjejí věci.

API reference, uživatelské příručky, návody a překlady. Techničtí autoři mohou navrhovat vylepšení prostřednictvím dokumentované trasy projektu a většina dokumentačních úkolů nevyžaduje programování. Zkontrolujte v projektu jeho nástroje a proces posouzení.

Opravy chyb, vylepšení výkonu, nové funkce a refaktorování. Několik nadací používá Rust, další jazyky se objevují tam, kde je projekt potřebuje. Řiďte se pokyny projektu pro přístup ke zdrojům, posouzení a testování; veřejné vstupní body nejsou zaručeny.

Softwarové inženýrství, dokumentace, zajišťování kvality a design. Dostupná trasa projektu a kontaktní osoba se liší podle nadace.

Příspěvky organizujeme do čtyř hlavních tras. Každá nadace popisuje svou dostupnou trasu, rozsah a podmínky posouzení. K práci můžete přistupovat jako jednotlivec, univerzitní výzkumná skupina nebo inženýrský tým, v závislosti na hranici přístupu projektu.

Kód, dokumentace, testování a design. Každá dovednost zde má své místo.

Týmy, které přispívají prostřednictvím trasy projektu, mohou získat hlubší odbornost než týmy, které ji pouze využívají. Inženýři se učí vnitřní fungování systémů, na kterých závisí, a mohou rozvíjet vztahy s maintainery, pokud projekt tento kontakt podporuje.

Dobře vymezený příspěvek může ovlivnit plán projektu, pokud jej maintaineři přijmou. Organizace by měly čas na příspěvky považovat za práci s jasným rozsahem, trasou posouzení a hranicí přístupu, nikoli za příslib kontroly nad produktem.

Viditelnost projektu se řídí plánem vydání. HEDL je veřejný; každá další nadace má nyní veřejný popis a svůj repozitář a dokumentaci, až přijde její kolo. Přečtěte si dokumentaci a licenci každého projektu, než se rozhodnete, co můžete prohlížet, ověřovat nebo znovu používat.

Dweve je zapsaná v Nizozemsku a vyvíjí v Evropské unii. Licence projektů, správa a nakládání s daty jsou popsány u každého projektu a mohou se lišit. Příspěvek sám o sobě nezakládá regulační shodu; ověřte si podmínky a důkazy, které se vztahují na vaše použití.