Contribute to Dweve AI Infrastructure

Funções a tempo inteiro em engenharia e produto. Remote-first dentro da UE.

Pergunte qual a rota do projeto, licença e termos de contribuição antes de enviar trabalho.

Notas de lançamento, análises aprofundadas e postmortems honestos da equipa.

Referências de API, guias de integração e documentação de arquitetura.

As fundações técnicas da Dweve, de Numerus e BitWeave a Lattice e AION. Verifique a rota de acesso de cada projeto antes de começar.

Depois de um projeto ser publicado, siga as instruções do repositório para propor um pull request. Antes disso, a página do projeto apresenta a sua ronda e os termos explicam a rota de revisão. Pode perguntar sobre isso em qualquer altura.

As alterações aceites são fundidas de acordo com a política do projeto.

Execute as verificações de CI que o projeto documenta para esta alteração.

As verificações documentadas aplicam-se.

Responda ao feedback e siga as regras de aprovação do projeto.

Abra um pull request quando o projeto o aceitar, referencie o issue se necessário e complete o seu modelo.

Execute os testes e verificações de qualidade documentados pelo projeto antes de abrir um pull request.

Executar verificações de qualidade localmente.

Assine os commits e siga o formato de commit apenas quando o projeto o exigir.

Crie uma branch de acordo com as instruções de nomenclatura do projeto.

Se o projeto for público e aceitar alterações, crie um fork conforme descrevem as suas instruções.

Cada passo tem uma expectativa clara. Use as verificações de qualidade que o projeto documenta.

Os projetos públicos podem usar um fluxo de trabalho fork-and-pull do GitHub. Verifique as instruções de cada projeto para nomes de branch, assinatura de commits, referências a issues, passos de revisão e expectativas de resposta.

Acesso, branch, revisão, fusão. Cada projeto documenta a sua rota.

Siga os requisitos de documentação do projeto para APIs públicas, exemplos e guias mais longos. Adicione contexto suficiente para outro contribuidor compreender e verificar a alteração.

Para alterações sensíveis ao desempenho, inclua contexto de benchmark quando o projeto o pedir. Registe o método, a base, o hardware e o resultado observado para que um revisor possa interpretar a afirmação.

Adicione testes adequados à alteração e siga as verificações do projeto para testes unitários, de integração, baseados em propriedades ou fuzzing. Descreva quaisquer limites de cobertura ou ambiente que afetem a revisão.

Testes unitários, de integração e de propriedades.

Portões de qualidade documentados para o projeto e a alteração.

Uma contribuição deve apresentar evidências que correspondam à sua alteração. Siga os testes documentados do projeto, as expectativas de referência e os requisitos de documentação; estes variam consoante o projeto e a via de acesso.

Utilize as verificações de testes, referências e documentação exigidas pelo projeto.

Para desenvolvimento nativo, utilize as dependências de sistema e plataformas documentadas pelo projeto. Alguns projetos fornecem instruções BUILD.md; consulte-as antes de começar.

Quando um projeto fornecer um fluxo de trabalho com contentores, siga as instruções de Docker ou Podman e utilize a imagem e os comandos documentados. Não assuma que o contentor corresponde ao CI sem verificar o registo do projeto.

Se o projeto utilizar Rust, instale o conjunto de ferramentas e os componentes indicados nas instruções de compilação. Requisitos como rustfmt, clippy, miri ou um MSRV são específicos do projeto.

Formas de preparar um ambiente de desenvolvimento. Consulte as instruções do projeto para a via suportada.

Conjunto de ferramentas, contentores e configuração nativa.

A via padrão depende do projeto. Leia as instruções de acesso e compilação, prepare o ambiente documentado, execute as verificações aplicáveis e utilize a via de revisão indicada.

Muitos projetos Dweve utilizam Rust, mas os conjuntos de ferramentas, versões mínimas, contentores e alvos de integração são específicos do projeto. Utilize a documentação atual do projeto como fonte de verdade.

Conjunto de ferramentas Rust, Docker e configuração local quando documentados.

Testes do projeto, Miri e verificações de fuzzing

Conjunto de ferramentas Rust, formatação e verificações de lint

A Dweve mantém catorze fundações técnicas que abrangem matemática, análise sintática, recuperação, políticas, simulação e verificação em tempo de execução. O HEDL é público no GitHub; as restantes publicam em rondas quinzenais a partir de 1 de setembro de 2026, duas de cada vez para começar. Comece pela licença de cada projeto e pela via indicada antes de enviar trabalho.

Explore as páginas das fundações. O HEDL é público agora, o AION e o Knot publicam a 1 de setembro de 2026, e todas as outras páginas indicam a ronda em que se encontram. A via do projeto explica como pedir ajuda.

As contribuições aceites podem ser creditadas nas notas de versão ou num registo de contribuidores, quando o projeto mantiver um. Consulte os termos do projeto para qualquer reconhecimento ou outro benefício.

As sessões de contribuidores podem ser anunciadas quando um projeto as agendar. Consulte a página do projeto ou contacte a Dweve para opções de participação atuais; localização, horário e suporte dependem do evento.

Pode pedir orientação para contribuir através do projeto ou da via de contacto. Se um mantenedor pode rever uma primeira alteração, que idioma está disponível e a rapidez de resposta dependem do projeto e da capacidade atual.

Orientação do projeto, sessões comunitárias e registos de contribuições dependem da via que escolher.

Orientação, sessões e registos do projeto.

Contribuir pode parecer intimidante. Comece com uma pergunta concreta, um relatório, uma alteração de documentação ou um teste. Quando um repositório expõe modelos de issue ou um ponto de entrada, utilize-os; caso contrário, solicite a via atual através da Dweve. O suporte e o tempo de resposta dependem do projeto.

As práticas de revisão dependem do projeto. Leia os termos de contribuição para saber quem pode rever uma alteração, que verificações se aplicam, como as preocupações de segurança são tratadas e se a discussão é pública.

Revisão por mantenedores quando exigida.

Verifique a licença e os termos de acesso ao código de cada projeto antes de integrar ou enviar trabalho. Se não estiverem indicados, contacte a Dweve antes de utilizar.

Os termos de contribuição variam por projeto. Consulte o repositório ou o canal de contacto para conhecer a licença aplicável, as condições de revisão e qualquer acordo solicitado antes de submeter.

Termos de contribuição, licença e revisão variam por projeto.

Termos de contribuição, licença e revisão.

A contribuição precisa de termos claros. A Dweve descreve o acesso atual, a licença e o canal de revisão de cada projeto. Os repositórios são publicados em rondas quinzenais a partir de 1 de setembro de 2026, por isso consulte o registo do projeto antes de investir tempo ou submeter trabalho.

Termos claros. Canal documentado. Responsabilidade partilhada.

Design de interface, auditorias de acessibilidade, iconografia e ativos de marca. Os designers podem propor trabalho para a Fabric, o site de documentação e as superfícies do projeto. Siga as orientações de marca e acessibilidade disponíveis e pergunte antes de reutilizar ficheiros ou tokens.

Experiência do utilizador e design visual.

Testes manuais, expansão de testes automatizados, fuzzing e benchmarking. Os testadores verificam que os novos lançamentos funcionam em hardware real e em fluxos de trabalho reais. Os fuzz testers encontram casos extremos que a lógica determinística deve tratar. Os benchmarkers validam as afirmações de desempenho. Este trilho é ideal para pessoas metódicas que gostam de encontrar falhas.

Referências de API, guias do utilizador, tutoriais e tradução. Os redatores técnicos podem propor melhorias através do canal documentado do projeto, e a maioria das tarefas de documentação não exige programação. Consulte o projeto para conhecer as suas ferramentas e o processo de revisão.

Correções de erros, melhorias de desempenho, novas funcionalidades e refatoração. Várias fundações usam Rust, com outras linguagens a aparecer onde o projeto precisar. Siga as instruções de acesso ao código, revisão e testes do projeto; os pontos de entrada públicos não são garantidos.

Engenharia de software, documentação, garantia de qualidade e design. O canal disponível do projeto e o ponto de contacto variam por fundação.

Quatro trilhos. Pontos de entrada claros.

Organizamos a contribuição em quatro trilhos abrangentes. Cada fundação descreve o seu canal disponível, âmbito e termos de revisão. Pode abordar o trabalho como indivíduo, grupo de investigação universitário ou equipa de engenharia, sujeito ao limite de acesso do projeto.

Código, docs, testes e design. Todas as competências têm lugar aqui.

As equipas que contribuem através do canal de um projeto podem desenvolver conhecimentos mais profundos do que as equipas que apenas o utilizam. Os engenheiros aprendem os detalhes internos dos sistemas de que dependem e podem desenvolver relações com os mantenedores quando o projeto apoia esse contacto.