Contribute to Dweve AI Infrastructure

Pełnoetatowe role w obszarach inżynierii i produktu. Praca zdalna w ramach UE.

Zapytaj, która ścieżka projektu, licencja i warunki współpracy obowiązują, zanim wyślesz pracę.

Notatki o wydaniach, szczegółowe analizy i szczere podsumowania po wdrożeniach od zespołu.

Dokumentacja API, przewodniki integracji i architektura.

Techniczne fundamenty Dweve, od Numerus i BitWeave po Lattice i AION. Sprawdź ścieżkę dostępu każdego projektu przed rozpoczęciem.

Gdy projekt zostanie opublikowany, postępuj zgodnie z instrukcjami w repozytorium, aby zaproponować pull request. Wcześniej strona projektu zawiera informacje o rundzie, a warunki wyjaśniają ścieżkę przeglądu. Możesz o to zapytać w dowolnym momencie.

Zaakceptowane zmiany są scalane zgodnie z polityką projektu.

Uruchom kontrolę CI, które projekt udokumentował dla tej zmiany.

Uwzględnij uwagi i postępuj zgodnie z zasadami zatwierdzania projektu.

Otwórz pull request, gdy projekt go akceptuje, odwołaj się do zgłoszenia, jeśli jest wymagane, i wypełnij jego szablon.

Uruchom testy i kontrole jakości udokumentowane przez projekt przed otwarciem pull requesta.

Podpisuj commity i przestrzegaj formatu commitów tylko wtedy, gdy projekt tego wymaga.

Postępuj zgodnie z zasadami commitów projektu.

Utwórz gałąź zgodnie z instrukcjami nazewnictwa projektu.

Jeśli projekt jest publiczny i akceptuje zmiany, utwórz fork zgodnie z jego instrukcjami.

Każdy krok ma jasne oczekiwania. Użyj kontroli jakości udokumentowanych przez projekt.

Od prośby o dostęp lub forka do przeglądu.

Projekty publiczne mogą korzystać z przepływu fork-and-pull na GitHubie. Sprawdź instrukcje każdego projektu dotyczące nazw gałęzi, podpisywania commitów, odwołań do zgłoszeń, kroków przeglądu i oczekiwań dotyczących odpowiedzi.

Dostęp, gałąź, przegląd, scalenie. Każdy projekt dokumentuje swoją ścieżkę.

Postępuj zgodnie z wymaganiami dokumentacyjnymi projektu dla publicznych API, przykładów i dłuższych przewodników. Dodaj wystarczająco dużo kontekstu, aby inny współpracownik mógł zrozumieć i sprawdzić zmianę.

W przypadku zmian wrażliwych na wydajność dołącz kontekst benchmarków, gdy projekt o to prosi. Zapisz metodę, punkt odniesienia, sprzęt i zaobserwowany wynik, aby recenzent mógł zinterpretować twierdzenie.

Dodaj testy odpowiednie do zmiany i postępuj zgodnie z kontrolami projektu dotyczącymi testów jednostkowych, integracyjnych, właściwościowych lub fuzz. Opisz wszelkie ograniczenia pokrycia lub środowiska, które wpływają na przegląd.

Testy jednostkowe, integracyjne i właściwościowe.

Bramki jakości udokumentowane dla projektu i zmiany.

Wkład powinien nieść dowody zgodne z wprowadzaną zmianą. Postępuj zgodnie z udokumentowanymi testami projektu, oczekiwaniami benchmarków i wymaganiami dokumentacyjnymi; różnią się one w zależności od projektu i sposobu dostępu.

Użyj testów, benchmarków i kontroli dokumentacji wymaganych przez projekt.

W przypadku rozwoju natywnego używaj zależności systemowych i platform udokumentowanych przez projekt. Niektóre projekty udostępniają instrukcje BUILD.md; sprawdź je przed rozpoczęciem.

Jeśli projekt udostępnia przepływ pracy z kontenerami, postępuj zgodnie z instrukcjami Docker lub Podman i używaj obrazu oraz poleceń, które dokumentuje. Nie zakładaj, że kontener odpowiada CI bez sprawdzenia dokumentacji projektu.

Jeśli projekt używa Rust, zainstaluj toolchain i komponenty wymienione w jego instrukcjach budowania. Wymagania takie jak rustfmt, clippy, miri lub MSRV są specyficzne dla projektu.

Sposoby przygotowania środowiska programistycznego. Sprawdź instrukcje projektu, aby poznać obsługiwaną ścieżkę.

Toolchain, kontenery i konfiguracja natywna.

Standardowa ścieżka zależy od projektu. Przeczytaj instrukcje dostępu i budowania, przygotuj udokumentowane środowisko, uruchom odpowiednie kontrole i skorzystaj z podanej ścieżki przeglądu.

Wiele projektów Dweve używa Rust, ale toolchainy, minimalne wersje, kontenery i cele integracji są specyficzne dla projektu. Używaj bieżącej dokumentacji projektu jako źródła prawdy.

Toolchain Rust, Docker i konfiguracja lokalna, jeśli udokumentowane.

Toolchain Rust, formatowanie i kontrole lint

Przeczytaj przewodnik dla współpracowników HEDL

Dweve utrzymuje czternaście fundamentów technicznych obejmujących matematykę, parsowanie, wyszukiwanie, politykę, symulację i weryfikację w czasie wykonywania. HEDL jest publiczny na GitHub; pozostałe publikowane są w dwutygodniowych rundach od 1 września 2026, początkowo po dwa na raz. Zacznij od licencji każdego projektu i podanej ścieżki przed wysłaniem pracy.

Przeglądaj strony fundamentów. HEDL jest teraz publiczny, AION i Knot publikują 1 września 2026, a każda inna strona podaje rundę, w której się znajduje. Ścieżka projektu wyjaśnia, jak poprosić o pomoc.

Zaakceptowane wkłady mogą zostać wymienione w notatkach wydania lub rejestrze współpracowników, jeśli projekt taki prowadzi. Sprawdź warunki projektu dotyczące uznania lub innych korzyści.

Sesje dla współpracowników mogą być ogłaszane, gdy projekt je zaplanuje. Sprawdź stronę projektu lub skontaktuj się z Dweve, aby poznać aktualne opcje uczestnictwa; lokalizacja, termin i wsparcie zależą od wydarzenia.

Możesz poprosić o wskazówki dotyczące wkładu przez projekt lub ścieżkę kontaktu. To, czy opiekun może przejrzeć pierwszą zmianę, jaki język jest dostępny i jak szybko ktoś odpowie, zależy od projektu i bieżących możliwości.

Wskazówki projektowe, sesje społeczności i rejestry wkładów zależą od wybranej ścieżki.

Wkład może wydawać się onieśmielający. Zacznij od konkretnego pytania, zgłoszenia, zmiany dokumentacji lub testu. Jeśli repozytorium udostępnia szablony zgłoszeń lub punkt wejścia, użyj go; w przeciwnym razie poproś o aktualną ścieżkę przez Dweve. Wsparcie i czas odpowiedzi zależą od projektu.

Praktyki przeglądu zależą od projektu. Przeczytaj jego warunki współpracy, aby dowiedzieć się, kto może przejrzeć zmianę, które kontrole mają zastosowanie, jak obsługiwane są kwestie bezpieczeństwa i czy dyskusja jest publiczna.

Sprawdź licencję i warunki dostępu do źródła dla każdego projektu przed integracją lub wysłaniem pracy. Jeśli nie są podane, skontaktuj się z Dweve przed użyciem.

Warunki licencji i dostępu dla projektu.

Warunki wkładu różnią się w zależności od projektu. Sprawdź repozytorium lub ścieżkę kontaktu, aby poznać obowiązującą licencję, warunki przeglądu oraz ewentualną umowę wymaganą przed przesłaniem.

Warunki wkładu, licencja i przegląd różnią się w zależności od projektu.

Wkład wymaga jasnych warunków. Dweve opisuje aktualny dostęp, licencję i ścieżkę przeglądu dla każdego projektu. Repozytoria publikowane są w dwutygodniowych rundach od 1 września 2026 r., więc sprawdź zapis projektu, zanim poświęcisz czas lub prześlesz pracę.

Jasne warunki. Udokumentowana ścieżka. Wspólna odpowiedzialność.

Projektowanie interfejsu, audyty dostępności, ikonografia i zasoby marki. Projektanci mogą proponować prace dla Fabric, strony dokumentacji i powierzchni projektów. Postępuj zgodnie z dostępnymi wytycznymi dotyczącymi marki i dostępności oraz pytaj przed ponownym użyciem plików lub tokenów.

Doświadczenie użytkownika i projektowanie wizualne.

Testy ręczne, rozszerzanie testów automatycznych, testy fuzz i benchmarki. Testerzy weryfikują, że nowe wydania działają na prawdziwym sprzęcie i w rzeczywistych przepływach pracy. Testerzy fuzz znajdują przypadki brzegowe, które powinna obsługiwać logika deterministyczna. Osoby tworzące benchmarki weryfikują twierdzenia o wydajności. Ten tor jest idealny dla metodycznych myślicieli, którzy lubią znajdować błędy.

Dokumentacja API, podręczniki użytkownika, samouczki i tłumaczenia. Autorzy dokumentacji technicznej mogą proponować ulepszenia przez udokumentowaną ścieżkę projektu, a większość zadań dokumentacyjnych nie wymaga kodowania. Sprawdź w projekcie jego narzędzia i proces przeglądu.

Poprawki błędów, ulepszenia wydajności, nowe funkcje i refaktoryzacja. Kilka fundamentów używa Rust, a inne języki pojawiają się tam, gdzie projekt ich potrzebuje. Postępuj zgodnie z instrukcjami projektu dotyczącymi dostępu do źródła, przeglądu i testów; publiczne punkty wejścia nie są gwarantowane.

Inżynieria oprogramowania, dokumentacja, zapewnienie jakości i projektowanie. Dostępna ścieżka projektu i punkt kontaktowy różnią się w zależności od fundamentu.

Organizujemy wkład w cztery szerokie tory. Każdy fundament opisuje swoją dostępną ścieżkę, zakres i warunki przeglądu. Możesz podejść do pracy jako osoba fizyczna, grupa badawcza uniwersytetu lub zespół inżynierski, z zastrzeżeniem granicy dostępu do projektu.

Kod, dokumentacja, testowanie i projektowanie. Każda umiejętność ma tu swoje miejsce.

Zespoły, które wnoszą wkład przez ścieżkę projektu, mogą zbudować głębszą wiedzę niż zespoły, które tylko z niej korzystają. Inżynierowie poznają wewnętrzne działanie systemów, od których zależą, i mogą nawiązać relacje z opiekunami, gdy projekt wspiera taki kontakt.

Dobrze zaplanowany wkład może wpłynąć na plan działania projektu, jeśli jego opiekunowie go zaakceptują. Organizacje powinny traktować czas poświęcony na wkład jako pracę z jasnym zakresem, ścieżką przeglądu i granicą dostępu, a nie jako obietnicę kontroli nad produktem.