Contribute to Dweve AI Infrastructure

Пълни позиции в инженерството и продукта. Работа предимно от разстояние в рамките на ЕС.

Попитайте кой път на проекта, лиценз и условия за принос се прилагат, преди да изпратите работа.

Бележки към изданието, задълбочени анализи и честни ретроспективи от екипа.

Справки за API, интеграционни ръководства и документация за архитектурата.

Техническите основи на Dweve, от Numerus и BitWeave до Lattice и AION. Проверете пътя за достъп на всеки проект, преди да започнете.

След като проект е публикуван, следвайте инструкциите в хранилището му, за да предложите pull request. Преди това страницата на проекта съдържа неговия кръг, а условията обясняват пътя за преглед. Можете да попитате за това по всяко време.

Приетите промени се сливат според политиката на проекта.

Изпълнете CI проверките, които проектът документира за тази промяна.

Отговорете на обратната връзка и следвайте правилата за одобрение на проекта.

Отворете pull request, когато проектът го приема, посочете issue, ако се изисква, и попълнете шаблона му.

Изпълнете тестовете и проверките за качество, документирани от проекта, преди да отворите pull request.

Изпълнете проверките за качество локално.

Подписвайте комитите и следвайте формата за комити само когато проектът го изисква.

Следвайте правилата за комити на проекта.

Създайте клон според инструкциите за именуване на проекта.

Ако проектът е публичен и приема промени, създайте форк, както описват инструкциите му.

Всяка стъпка има ясно очакване. Използвайте проверките за качество, които проектът документира.

От заявка за достъп или форк до преглед.

Публичните проекти може да използват GitHub работен процес fork-and-pull. Проверете инструкциите на всеки проект за имена на клонове, подписване на комити, позовавания на issue, стъпки за преглед и очаквания за отговор.

Достъп, клон, преглед, сливане. Всеки проект документира своя път.

Следвайте изискванията за документация на проекта за публични API, примери и по-дълги ръководства. Добавете достатъчно контекст, за да може друг сътрудник да разбере и провери промяната.

За промени, чувствителни към производителността, включете контекст за бенчмаркове, когато проектът го изисква. Запишете метода, базовата линия, хардуера и наблюдавания резултат, така че рецензентът да може да интерпретира твърдението.

Добавете тестове, подходящи за промяната, и следвайте проверките на проекта за unit, интеграционни, property-based или fuzz тестове. Опишете всички ограничения на покритието или средата, които засягат прегледа.

Качествени порти, документирани за проекта и промяната.

Приносът трябва да носи доказателства, които съответстват на промяната. Следвайте документираните тестове, очакванията за бенчмаркове и изискванията за документация на проекта; те варират според проекта и начина на достъп.

Използвайте проверките за тестове, бенчмаркове и документация, които проектът изисква.

За нативна разработка използвайте системните зависимости и платформи, документирани от проекта. Някои проекти предоставят инструкции в BUILD.md; проверете ги, преди да започнете.

Когато проектът предоставя работен процес с контейнери, следвайте неговите инструкции за Docker или Podman и използвайте образа и командите, които документира. Не предполагайте, че контейнерът съвпада с CI, без да проверите записа на проекта.

Ако проектът използва Rust, инсталирайте инструментариума и компонентите, посочени в неговите инструкции за изграждане. Изисквания като rustfmt, clippy, miri или MSRV са специфични за проекта.

Начини за подготовка на среда за разработка. Проверете инструкциите на проекта за поддържания път.

Инструментариум, контейнери и нативна настройка.

Стандартният път зависи от проекта. Прочетете инструкциите за достъп и изграждане, подгответе документираната среда, изпълнете приложимите проверки и използвайте посочения път за преглед.

Много проекти на Dweve използват Rust, но инструментариумите, минималните версии, контейнерите и интеграционните цели са специфични за проекта. Използвайте текущата документация на проекта като източник на истина.

Rust инструментариум, Docker и локална настройка, където е документирано.

Тестове на проекта, Miri и fuzz проверки

Rust инструментариум, форматиране и lint проверки

Прочетете ръководството за принос на HEDL

Dweve поддържа четиринадесет технически основи, обхващащи математика, синтактичен анализ, извличане, политики, симулация и проверка по време на изпълнение. HEDL е публичен в GitHub; останалите публикуват на двуседмични кръгове от 1 септември 2026 г., като в началото по два наведнъж. Започнете с лиценза на всеки проект и посочения път, преди да изпратите работа.

Разгледайте страниците на основите. HEDL е публичен сега, AION и Knot публикуват на 1 септември 2026 г., а всяка друга страница посочва кръга, в който се намира. Пътят на проекта обяснява как да поискате помощ.

Приетите приноси могат да бъдат отбелязани в бележките към изданието или в записа на сътрудниците, когато проектът поддържа такъв. Проверете условията на проекта за всяко признание или друга полза.

Сесии за сътрудници могат да бъдат обявени, когато проектът ги планира. Проверете страницата на проекта или се свържете с Dweve за текущите възможности за участие; местоположението, времето и подкрепата зависят от събитието.

Можете да поискате насоки за принос чрез проекта или пътя за контакт. Дали поддържащ може да прегледа първа промяна, кой език е наличен и колко бързо някой отговаря, зависи от проекта и текущия капацитет.

Насоки за проекта, обществени сесии и записи на приноси зависят от избрания път.

Приносът може да изглежда плашещ. Започнете с конкретен въпрос, доклад, промяна в документацията или тест. Където хранилището предоставя шаблони за проблеми или входна точка, използвайте ги; в противен случай поискайте текущия път чрез Dweve. Подкрепата и времето за отговор зависят от проекта.

Практиките за преглед зависят от проекта. Прочетете условията за принос, за да видите кой може да прегледа промяна, кои проверки се прилагат, как се обработват опасенията за сигурност и дали дискусията е публична.

Преглед от поддържащ, където се изисква.

Проверете лиценза и условията за достъп до изходния код за всеки проект, преди да интегрирате или изпратите работа. Ако не са посочени, свържете се с Dweve преди употреба.

Условия за лиценз и достъп за всеки проект.

Условията за принос варират според проекта. Проверете хранилището или контактния маршрут за приложимия лиценз, условията за преглед и евентуално изисквано споразумение, преди да изпратите.

Условията за принос, лицензът и прегледът варират според проекта.

Приносът изисква ясни условия. Dweve описва текущия достъп, лиценз и маршрут за преглед за всеки проект. Хранилищата публикуват на двуседмични цикли от 1 септември 2026 г., така че проверете записа на проекта, преди да отделите време или да изпратите работа.

Ясни условия. Документиран маршрут. Споделена отговорност.

Дизайн на интерфейса, одити на достъпността, иконография и бранд активи. Дизайнерите могат да предлагат работа за Fabric, сайта за документация и проектните повърхности. Следвайте наличните насоки за бранда и достъпността и питайте, преди да използвате повторно файлове или токени.

Потребителско изживяване и визуален дизайн.

Ръчно тестване, разширяване на автоматизираните тестове, фъз тестване и бенчмаркинг. Тестващите проверяват, че новите версии работят на реални устройства и в реални работни процеси. Фъз тестващите откриват крайни случаи, които детерминистичната логика трябва да обработва. Бенчмаркиращите валидират твърденията за производителност. Този поток е идеален за методични мислители, които обичат да разбиват неща.

API референции, потребителски ръководства, уроци и превод. Техническите писатели могат да предлагат подобрения чрез документирания маршрут на проекта, а повечето задачи за документация не изискват програмиране. Проверете проекта за неговите инструменти и процес на преглед.

Поправки на грешки, подобрения на производителността, нови функции и рефакторинг. Няколко фондации използват Rust, като други езици се появяват там, където проектът има нужда от тях. Следвайте инструкциите на проекта за достъп до изходния код, преглед и тестване; публичните входни точки не са гарантирани.

Софтуерно инженерство, документация, осигуряване на качество и дизайн. Наличният маршрут на проекта и точката за контакт варират според фондацията.

Организираме приноса в четири широки потока. Всяка фондация описва своя наличен маршрут, обхват и условия за преглед. Можете да подходите към работата като индивидуален, университетска изследователска група или инженерен екип, в зависимост от границата на достъп на проекта.

Код, документация, тестване и дизайн. Всяко умение има място тук.

Екипите, които допринасят чрез маршрута на даден проект, могат да изградят по-задълбочена експертиза от екипите, които само го използват. Инженерите научават вътрешностите на системите, от които зависят, и могат да развият взаимоотношения с поддържащите, когато проектът подкрепя този контакт.

Добре обхванат принос може да информира пътната карта на проекта, когато неговите поддържащи го приемат. Организациите трябва да третират времето за принос като работа с ясен обхват, маршрут за преглед и граница на достъп, а не като обещание за контрол върху продукта.