Contribute to Dweve AI Infrastructure

Pilna laika amati inženierijā un produktā. Attālināts darbs ES teritorijā.

Pirms darba nosūtīšanas jautājiet, kurš projekta ceļš, licence un ieguldījuma noteikumi ir piemērojami.

Laidiena piezīmes, padziļināti apraksti un godīgas pēcrecesijas no komandas.

API atsauces, integrācijas ceļveži un arhitektūras dokumentācija.

Dweve tehniskie pamati, sākot no Numerus un BitWeave līdz Lattice un AION. Pirms sākat, pārbaudiet katra projekta piekļuves ceļu.

Kad projekts ir publicēts, sekojiet tā repozitorija norādēm, lai ierosinātu izmaiņu pieprasījumu. Pirms tam projekta lapā ir norādīta tā kārta, un noteikumi izskaidro pārskatīšanas ceļu. Par to varat jautāt jebkurā brīdī.

Pieņemtās izmaiņas tiek apvienotas saskaņā ar projekta politiku.

Palaidiet CI pārbaudes, ko projekts dokumentē šīm izmaiņām.

Atbildiet uz atsauksmēm un ievērojiet projekta apstiprināšanas noteikumus.

Atveriet izmaiņu pieprasījumu, ja projekts to pieņem, norādiet problēmu, ja tas ir nepieciešams, un aizpildiet tā veidni.

Pirms izmaiņu pieprasījuma atvēršanas palaidiet testus un kvalitātes pārbaudes, ko projekts dokumentē.

Parakstiet commit un ievērojiet commit formātu tikai tad, ja projekts to pieprasa.

Izveidojiet atzaru saskaņā ar projekta nosaukšanas norādēm.

Ja projekts ir publisks un pieņem izmaiņas, izveidojiet fork, kā aprakstīts tā norādēs.

Katram solim ir skaidras cerības. Izmantojiet kvalitātes pārbaudes, ko projekts dokumentē.

No piekļuves pieprasījuma vai fork līdz pārskatīšanai.

Publiskie projekti var izmantot GitHub fork-and-pull darbplūsmu. Pārbaudiet katra projekta norādes par atzaru nosaukumiem, commit parakstīšanu, problēmu atsaucēm, pārskatīšanas soļiem un atbildes cerībām.

Piekļuve, atzars, pārskats, apvienošana. Katrs projekts dokumentē savu ceļu.

Ievērojiet projekta dokumentācijas prasības publiskajiem API, piemēriem un garākiem ceļvežiem. Pievienojiet pietiekami daudz konteksta, lai cits ieguldītājs varētu saprast un pārbaudīt izmaiņas.

Veiktspējas jutīgām izmaiņām iekļaujiet etalonu kontekstu, ja projekts to pieprasa. Ierakstiet metodi, bāzes līniju, aparatūru un novēroto rezultātu, lai recenzents varētu interpretēt apgalvojumu.

Pievienojiet izmaiņām atbilstošus testus un ievērojiet projekta pārbaudes vienību, integrācijas, īpašību vai fuzz testēšanai. Aprakstiet visus pārklājuma vai vides ierobežojumus, kas ietekmē pārskatīšanu.

Kvalitātes vārti, kas dokumentēti projektam un izmaiņām.

Ieguldījumam jāsniedz pierādījumi, kas atbilst tā izmaiņām. Ievērojiet projekta dokumentētos testus, etalonu prasības un dokumentācijas prasības; tās atšķiras atkarībā no projekta un piekļuves veida.

Izmantojiet testēšanas, etalonu un dokumentācijas pārbaudes, ko projekts pieprasa.

Vietējai izstrādei izmantojiet sistēmas atkarības un platformas, ko projekts dokumentējis. Daži projekti nodrošina BUILD.md instrukcijas; pārbaudiet tās pirms sākat.

Ja projektam ir konteinera darbplūsma, ievērojiet tā Docker vai Podman instrukcijas un izmantojiet attēlu un komandas, ko tas dokumentējis. Nepieņemiet, ka konteiners atbilst CI, nepārbaudot projekta ierakstu.

Ja projekts izmanto Rust, instalējiet rīkkopu un komponentus, kas nosaukti tā būvēšanas instrukcijās. Prasības, piemēram, rustfmt, clippy, miri vai MSRV, ir projekta specifiskas.

Veidi, kā sagatavot izstrādes vidi. Pārbaudiet projekta instrukcijas par atbalstīto ceļu.

Rīkkopa, konteineri un vietējā iestatīšana.

Standarta ceļš ir atkarīgs no projekta. Izlasiet tā piekļuves un būvēšanas instrukcijas, sagatavojiet dokumentēto vidi, veiciet piemērojamās pārbaudes un izmantojiet norādīto pārskatīšanas ceļu.

Daudzi Dweve projekti izmanto Rust, bet rīkkopas, minimālās versijas, konteineri un integrācijas mērķi ir projekta specifiski. Izmantojiet pašreizējo projekta dokumentāciju kā patiesības avotu.

Rust rīkkopa, Docker un vietējā iestatīšana, ja dokumentēta.

Uzturētāja pārskatīšana, ja nepieciešama

Rust rīkkopa, formatēšana un lint pārbaudes

Dweve uztur četrpadsmit tehniskos pamatus, kas aptver matemātiku, parsēšanu, izguvi, politiku, simulāciju un izpildlaika verifikāciju. HEDL ir publisks GitHub; pārējie tiek publicēti divu nedēļu ciklos no 2026. gada 1. septembra, sākumā divi vienlaikus. Sāciet ar katra projekta licenci un norādīto ceļu, pirms sūtāt darbu.

Pārlūkojiet pamatu lapas. HEDL ir publisks tagad, AION un Knot publicējas 2026. gada 1. septembrī, un katra cita lapa nosauc kārtu, kurā tā atrodas. Projekta ceļš izskaidro, kā lūgt palīdzību.

Pieņemtie ieguldījumi var tikt minēti laidiena piezīmēs vai ieguldītāju ierakstā, ja projekts tādu uztur. Pārbaudiet projekta noteikumus par jebkādu atzinību vai citu labumu.

Ieguldītāju sesijas var tikt paziņotas, ja projekts tās plāno. Pārbaudiet projekta lapu vai sazinieties ar Dweve, lai uzzinātu pašreizējās dalības iespējas; vieta, laiks un atbalsts ir atkarīgi no pasākuma.

Jūs varat lūgt ieguldījumu norādījumus, izmantojot projekta vai kontaktpersonas ceļu. Vai uzturētājs var pārskatīt pirmās izmaiņas, kura valoda ir pieejama un cik ātri kāds atbild, ir atkarīgs no projekta un pašreizējās kapacitātes.

Projekta norādījumi, kopienas sesijas un ieguldījumu ieraksti ir atkarīgi no izvēlētā ceļa.

Norādījumi, sesijas un projekta ieraksti.

Ieguldīšana var šķist biedējoša. Sāciet ar konkrētu jautājumu, ziņojumu, dokumentācijas izmaiņu vai testu. Ja repozitorijs piedāvā problēmu veidnes vai ieejas punktu, izmantojiet to; pretējā gadījumā pieprasiet pašreizējo ceļu caur Dweve. Atbalsts un atbildes laiks ir atkarīgs no projekta.

Atbalsts notiek saskaņā ar projekta ceļu.

Pārskatīšanas prakse ir atkarīga no projekta. Izlasiet tā ieguldījumu noteikumus, lai redzētu, kurš var pārskatīt izmaiņas, kuras pārbaudes attiecas, kā tiek risinātas drošības problēmas un vai diskusija ir publiska.

Uzturētāja pārskatīšana, ja nepieciešama.

Pārbaudiet licences un avota piekļuves noteikumus katram projektam pirms integrēšanas vai darba nosūtīšanas. Ja tie nav norādīti, sazinieties ar Dweve pirms lietošanas.

Licences un piekļuves noteikumi katram projektam.

Ieguldījuma noteikumi atšķiras atkarībā no projekta. Pirms iesniegšanas pārbaudiet repozitoriju vai kontaktinformāciju, lai uzzinātu piemērojamo licenci, pārskatīšanas nosacījumus un jebkuru pieprasīto vienošanos.

Ieguldījuma noteikumi, licence un pārskatīšana atšķiras atkarībā no projekta.

Ieguldījuma noteikumi, licence un pārskatīšana.

Ieguldījumam nepieciešami skaidri noteikumi. Dweve apraksta pašreizējo piekļuves, licences un pārskatīšanas kārtību katram projektam. Repozitoriji tiek publicēti divu nedēļu ciklos no 2026. gada 1. septembra, tāpēc pirms laika vai darba ieguldīšanas pārbaudiet projekta ierakstu.

Skaidri noteikumi. Dokumentēta kārtība. Kopīga atbildība.

Saskarnes dizains, pieejamības auditi, ikonogrāfija un zīmola materiāli. Dizaineri var ierosināt darbu Fabric, dokumentācijas vietnei un projekta virsmām. Ievērojiet pieejamās zīmola un pieejamības vadlīnijas, un jautājiet pirms failu vai marķieru atkārtotas izmantošanas.

Lietotāja pieredze un vizuālais dizains.

Manuālā testēšana, automatizēto testu paplašināšana, fuzz testēšana un veiktspējas mērījumi. Testētāji pārliecinās, ka jaunās versijas darbojas uz reālām ierīcēm un reālos darba procesos. Fuzz testētāji atrod malējos gadījumus, kas deterministiskajai loģikai būtu jāapstrādā. Veiktspējas mērītāji apstiprina veiktspējas apgalvojumus. Šis virziens ir ideāls metodiskiem domātājiem, kuriem patīk lauzt lietas.

API atsauces, lietotāja rokasgrāmatas, apmācības un tulkošana. Tehniskie rakstnieki var ierosināt uzlabojumus, izmantojot dokumentēto projekta kārtību, un lielākajai daļai dokumentācijas uzdevumu nav nepieciešama programmēšana. Pārbaudiet projekta rīkus un pārskatīšanas procesu.

Kļūdu labojumi, veiktspējas uzlabojumi, jaunas funkcijas un refaktorēšana. Vairāki pamati izmanto Rust, citās valodās parādās tur, kur projekts tās pieprasa. Ievērojiet projekta pirmkoda piekļuves, pārskatīšanas un testēšanas instrukcijas; publiskie ievades punkti nav garantēti.

Programmatūras inženierija, dokumentācija, kvalitātes nodrošināšana un dizains. Pieejamā projekta kārtība un kontaktpersona atšķiras atkarībā no pamata.

Mēs organizējam ieguldījumu četros plašos virzienos. Katrs pamats apraksta savu pieejamo kārtību, darbības jomu un pārskatīšanas noteikumus. Jūs varat pievērsties darbam kā indivīds, universitātes pētniecības grupa vai inženieru komanda, ievērojot projekta piekļuves robežu.

Kods, dokumentācija, testēšana un dizains. Katrai prasmei šeit ir vieta.

Komandas, kas iegulda caur projekta kārtību, var iegūt dziļākas zināšanas nekā komandas, kas to tikai patērē. Inženieri apgūst sistēmu iekšējo darbību, no kurām tās ir atkarīgas, un var veidot attiecības ar uzturētājiem, ja projekts atbalsta šo saziņu.

Labi definēts ieguldījums var ietekmēt projekta ceļvedi, ja tā uzturētāji to pieņem. Organizācijām būtu jāuztver ieguldījuma laiks kā darbs ar skaidru darbības jomu, pārskatīšanas kārtību un piekļuves robežu, nevis kā produkta kontroles solījums.

Projekta redzamība seko publicēšanas grafikam. HEDL ir publisks; katram citam pamatam tagad ir publisks apraksts, un tā repozitorijs un dokumentācija parādīsies, kad pienāks tā kārta. Izlasiet katra projekta dokumentāciju un licenci, pirms izlemjat, ko varat pārbaudīt, apstiprināt vai atkārtoti izmantot.