Como começar a contribuir para um projeto de descompilação

Comece por uma tarefa verificável em um projeto que desperte seu interesse. Sua primeira contribuição não precisa ser uma função difícil. Reproduzir uma compilação, esclarecer um requisito ou registrar um teste ajuda quem vier depois.

Encontre um projeto e use a documentação dele para ferramentas, branches e regras. O DecompHub não atribui tarefas nem representa os mantenedores.

Confira o ambiente

Em Posso ajudar, informe se tem macOS, Windows ou Linux. São preferências privadas de busca, não garantia de compilação no seu computador.

Verifique sistema, compilador e revisão exatos. Super Mario 64 distingue processos para Linux, macOS e contêineres, além das entradas por versão. Uma instrução de outro fork pode produzir um build comparado ao alvo errado.

Registre commit e versões das ferramentas. Confira previamente se precisa de dados originais ou hardware específico; o catálogo não os fornece.

Leia as regras

Procure CONTRIBUTING, documentação e processo de revisão. O GitHub explica onde aparecem essas orientações.

Pode ser necessário abrir um issue, usar uma branch específica ou executar verificações. Respeite também a política de contribuições geradas por IA. Uma tarefa inicial deve ter conclusão clara: build reproduzido, função correspondente, instrução corrigida ou falha demonstrada.

Registre uma base reproduzível

Execute a validação antes de editar. Guarde comando, alvo, ferramentas e resultado. Se a base já falha, investigue isso separadamente.

Um relato útil explica resultado esperado, observado e passos mínimos para reproduzir. Inclua apenas logs relevantes. Indicar comando, etapa e versão é mais útil que dizer apenas que “não funciona”.

Contribua com evidências

• Documentação: corrija uma etapa testada, um requisito ambíguo ou um link oficial.
• Testes: siga um procedimento publicado e registre versão e resultado reproduzível.
• Código correspondente: comece com uma função pequena e compreendida. O decomp.me permite experimentar com a saída do compilador; depois valide no projeto.
• Ferramentas: melhore uma rotina repetível ou mensagem de erro, preservando as verificações adotadas.

O objdiff descreve outro fluxo de comparação. Prefira as ferramentas indicadas pelo repositório a introduzir uma segunda estrutura por hábito.

Envie uma mudança focada

Explique problema, comportamento resultante e validação. No matching, cite alvo e comparação. Na documentação, diga o que testou. Declare o que não foi verificado.

Evite misturar a tarefa com uma limpeza geral. Mudanças pequenas e demonstráveis facilitam a revisão. Se o repositório estiver parado ou arquivado, procure um sucessor documentado antes de esperar retorno.

Envie a URL oficial se ele não estiver no catálogo. O guia de progresso ajuda a entender seus números.