Contribute to Dweve AI Infrastructure

Ruoli a tempo pieno in ingegneria e prodotto. Remote-first nell'UE.

Chiedi informazioni sul percorso del progetto, sulla licenza e sui termini di contribuzione prima di inviare il lavoro.

Note di rilascio, approfondimenti e postmortem onesti dal team.

Riferimenti API, guide di integrazione e documentazione sull'architettura.

Le fondamenta tecniche di Dweve, da Numerus e BitWeave a Lattice e AION. Controlla il percorso di accesso di ciascun progetto prima di iniziare.

Una volta che un progetto è stato pubblicato, segui le istruzioni del suo repository per proporre una pull request. Prima di ciò, la pagina del progetto riporta il suo ciclo e i termini spiegano il percorso di revisione. Puoi chiedere informazioni in qualsiasi momento.

Le modifiche accettate vengono unite secondo la policy del progetto.

Esegui i controlli CI che il progetto documenta per questa modifica.

Affronta il feedback e segui le regole di approvazione del progetto.

Apri una pull request quando il progetto la accetta, fai riferimento all'issue se richiesto e completa il suo template.

Esegui i test e i controlli di qualità documentati dal progetto prima di aprire una pull request.

Esegui i controlli di qualità in locale.

Firma i commit e segui il formato dei commit solo quando il progetto lo richiede.

Segui le regole sui commit del progetto.

Crea un branch secondo le istruzioni di denominazione del progetto.

Se il progetto è pubblico e accetta modifiche, crea un fork come descritto nelle sue istruzioni.

Ogni passaggio ha un'aspettativa chiara. Usa i controlli di qualità che il progetto documenta.

Dalla richiesta di accesso o dal fork alla revisione.

I progetti pubblici possono usare un flusso di lavoro fork-and-pull su GitHub. Controlla le istruzioni di ciascun progetto per nomi di branch, firma dei commit, riferimenti alle issue, passaggi di revisione e aspettative di risposta.

Accesso, branch, revisione, merge. Ogni progetto documenta il suo percorso.

Segui i requisiti di documentazione del progetto per API pubbliche, esempi e guide più lunghe. Aggiungi abbastanza contesto affinché un altro contributore possa comprendere e verificare la modifica.

Per modifiche sensibili alle prestazioni, includi il contesto di benchmark quando il progetto lo richiede. Registra il metodo, la baseline, l'hardware e il risultato osservato affinché un revisore possa interpretare l'affermazione.

Aggiungi test appropriati alla modifica e segui i controlli del progetto per test unitari, di integrazione, basati su proprietà o fuzz. Descrivi eventuali limiti di copertura o ambiente che influenzano la revisione.

Test unitari, di integrazione e basati su proprietà.

Gate di qualità documentati per il progetto e la modifica.

Una contribuzione dovrebbe portare con sé prove che corrispondano alla sua modifica. Segui i test documentati del progetto, le aspettative di benchmark e i requisiti di documentazione; variano a seconda del progetto e della via di accesso.

Usa i controlli di test, benchmark e documentazione richiesti dal progetto.

Per lo sviluppo nativo, usa le dipendenze di sistema e le piattaforme documentate dal progetto. Alcuni progetti forniscono istruzioni BUILD.md; controllale prima di iniziare.

Dove un progetto prevede un flusso di lavoro con container, segui le sue istruzioni Docker o Podman e usa l'immagine e i comandi che documenta. Non dare per scontato che il container corrisponda alla CI senza verificare la documentazione del progetto.

Se il progetto usa Rust, installa la toolchain e i componenti indicati nelle sue istruzioni di build. Requisiti come rustfmt, clippy, miri o un MSRV sono specifici del progetto.

Modi per preparare un ambiente di sviluppo. Controlla le istruzioni del progetto per il percorso supportato.

Toolchain, container e configurazione nativa.

Il percorso standard dipende dal progetto. Leggi le sue istruzioni di accesso e build, prepara l'ambiente documentato, esegui i controlli pertinenti e usa la via di revisione indicata.

Molti progetti Dweve usano Rust, ma toolchain, versioni minime, container e obiettivi di integrazione sono specifici del progetto. Usa la documentazione attuale del progetto come fonte di verità.

Toolchain Rust, Docker e configurazione locale dove documentati.

Test del progetto, Miri e controlli fuzz

Toolchain Rust, formattazione e controlli lint

Leggi la guida alle contribuzioni di HEDL

Dweve mantiene quattordici fondamenta tecniche che spaziano tra matematica, parsing, recupero, policy, simulazione e verifica runtime. HEDL è pubblico su GitHub; le altre pubblicano a cicli quindicinali a partire dal 1 settembre 2026, inizialmente due alla volta. Inizia con la licenza di ogni progetto e la via indicata prima di inviare lavoro.

Sfoglia le pagine delle fondamenta. HEDL è pubblico ora, AION e Knot pubblicano il 1 settembre 2026, e ogni altra pagina indica il ciclo in cui si trova. La via del progetto spiega come chiedere aiuto.

Le contribuzioni accettate possono essere riconosciute nelle note di rilascio o in un registro dei contributori quando il progetto ne tiene uno. Controlla i termini del progetto per qualsiasi riconoscimento o altro beneficio.

Riconoscimento nel registro del progetto.

Le sessioni per contributori possono essere annunciate quando un progetto le programma. Controlla la pagina del progetto o contatta Dweve per le opzioni di partecipazione attuali; posizione, tempi e supporto dipendono dall'evento.

Puoi chiedere indicazioni sulle contribuzioni tramite il progetto o la via di contatto. Se un maintainer può rivedere una prima modifica, quale lingua è disponibile e quanto velocemente qualcuno risponde dipendono dal progetto e dalla capacità attuale.

Indicazioni di progetto, sessioni comunitarie e registri delle contribuzioni dipendono dalla via che scegli.

Indicazioni, sessioni e registri di progetto.

Contribuire può sembrare intimidatorio. Inizia con una domanda concreta, una segnalazione, una modifica alla documentazione o un test. Dove un repository espone modelli di issue o un punto di ingresso, usalo; altrimenti richiedi la via attuale tramite Dweve. Supporto e tempi di risposta dipendono dal progetto.

Le pratiche di revisione dipendono dal progetto. Leggi i suoi termini di contribuzione per vedere chi può rivedere una modifica, quali controlli si applicano, come vengono gestite le questioni di sicurezza e se la discussione è pubblica.

Revisione del maintainer dove richiesta.

Controlla la licenza e i termini di accesso alla fonte per ogni progetto prima di integrare o inviare lavoro. Se non sono indicati, contatta Dweve prima dell'uso.

Termini di licenza e accesso per progetto.

I termini di contribuzione variano da progetto a progetto. Controlla il repository o la via di contatto per la licenza applicabile, le condizioni di revisione e qualsiasi accordo richiesto prima di inviare.

Termini di contribuzione, licenza e revisione variano da progetto a progetto.

Termini di contribuzione, licenza e revisione.

La contribuzione richiede termini chiari. Dweve descrive l'accesso attuale, la licenza e la via di revisione per ogni progetto. I repository vengono pubblicati a cicli quindicinali a partire dal 1 settembre 2026, quindi controlla il record del progetto prima di impegnare tempo o inviare lavoro.

Termini chiari. Via documentata. Responsabilità condivisa.

Design dell'interfaccia, audit di accessibilità, iconografia e risorse del marchio. I designer possono proporre lavoro per Fabric, il sito di documentazione e le superfici del progetto. Segui le linee guida disponibili su marchio e accessibilità e chiedi prima di riutilizzare file o token.

Test manuali, espansione dei test automatizzati, fuzz testing e benchmarking. I tester verificano che le nuove versioni funzionino su hardware reale e in flussi di lavoro reali. I fuzz tester trovano casi limite che la logica deterministica dovrebbe gestire. I benchmarker convalidano le affermazioni sulle prestazioni. Questa traccia è ideale per pensatori metodici che amano scovare problemi.

Riferimenti API, guide utente, tutorial e traduzione. I technical writer possono proporre miglioramenti attraverso la via documentata del progetto e la maggior parte delle attività di documentazione non richiede codifica. Controlla il progetto per i suoi strumenti e il processo di revisione.

Correzioni di bug, miglioramenti delle prestazioni, nuove funzionalità e refactoring. Diverse fondazioni usano Rust, con altri linguaggi dove il progetto lo richiede. Segui le istruzioni del progetto su accesso al codice sorgente, revisione e test; i punti di ingresso pubblici non sono garantiti.

Ingegneria del software, documentazione, assicurazione qualità e design. La via di progetto disponibile e il punto di contatto variano da fondazione a fondazione.

Quattro tracce. Punti di ingresso chiari.

Organizziamo la contribuzione in quattro ampie tracce. Ogni fondazione descrive la sua via disponibile, l'ambito e i termini di revisione. Puoi affrontare il lavoro come individuo, gruppo di ricerca universitario o team di ingegneria, soggetto al confine di accesso del progetto.