Como começar a corrigir erros no software de código aberto?

Eu sou um estudante com bons conhecimentos em programação C e gostaria de contribuir com qualquer projeto de código aberto desenvolvido em C. Eu pesquisei no SourceForge e selecionei o 7-Zip porque ele é amplamente usado e desenvolvido usando C.

Pensei em começar primeiro corrigindo bugs (o que foi sugerido por muitas pessoas em seus sites) e resolvi alguns bugs, mas não conseguia entender como responder a eles e como começar a corrigi-los. Eu não entendi nada.

Poderia explicar como abordar isso? Eu até passei por alguns arquivos no código-fonte que baixei, mas não entendi nada.

Aqui está uma sugestão:
Solicitações de recursos: use "mover" em vez de "copiar" da pasta temp - ID: 1615140

Você pode alterar o comportamento do 7-zip para usar "mover" em vez de "copiar" quando o 7-zip descompacta os arquivos. O problema é com sistemas únicos de HDD e arquivos grandes, isso acelerará significativamente as coisas. O WinRAR faz isso agora.

E vou explicar por que escolhi esse bug como exemplo.

Antes de decidir escolher este projeto ...

• Você se sente confortável com o código-fonte deste projeto?
  • Você consegue entender o código C (principalmente os algoritmos de compactação do núcleo)?
  • E também o código C ++ (a maioria da "aplicação", GUI e linha de comando, e também todas as interações com os sistemas operacionais)?
  • E também o estilo de codificação (típico da programação Win32; não usando MFC / ATL)?
• Você investirá seu tempo e esforço neste sistema operacional?
  • É necessário um bom entendimento da API do Windows.
  • Por exemplo: Funções da API de gerenciamento de arquivos do Windows .

Primeiro passo: você pode reproduzir o bug?

• Para escolher um bug para trabalhar, é necessário poder reproduzir o problema em um ambiente de computador semelhante.
  • Esse bug exigirá que você teste em um computador que (1) a temppasta tenha pouco espaço livre (1-2 GB), (2) o destino da extração esteja na mesma unidade da temppasta.
• Quanto tempo é necessário para "configurar" o ambiente para reproduzi-lo?
  • Escolha bugs fáceis de reproduzir e de corrigir.
• O bug é realmente um bug?
  • Sempre tente reproduzi-lo você mesmo. Não confie apenas nas palavras dos outros.
  • Como engenheiro / programador de software, veja se você pode explicar o comportamento do bug em termos de sua compreensão. Às vezes, os usuários têm expectativas irreais de como os sistemas de software / hardware funcionam e fazem solicitações de recursos impossíveis.
• Como confirmo meu entendimento? Como sei se ele está copiando ou movendo o arquivo?
  • Você precisará de ferramentas de diagnóstico, como o Process Monitor . Você também pode ajustar a configuração da sua máquina de teste para testar diferentes cenários.

Segunda etapa: você pode localizar o código responsável por esse comportamento?

• É necessário um entendimento geral aproximado do projeto, de acordo com a resposta de Larry Coleman .
• É melhor se você tiver o Visual Studio (um ambiente de desenvolvimento e depurador integrado) para poder definir pontos de interrupção e entender o fluxo do programa.

Terceiro passo: Faça modificações e veja como isso afeta o comportamento do programa.

Quarto passo: apresente suas alterações aos colegas de trabalho / desenvolvedores de colegas e obtenha feedback.

A correção de bugs pode não ser a coisa mais fácil. É mais fácil do que adicionar novos recursos, é claro. Mas ainda mais fácil é atualizar a documentação ou testar uma nova versão. Ambos farão com que você se familiarize com o código, para que você saiba o suficiente para corrigir um bug. Também fornece ao aprendizado sobre o código um senso de propósito que ajuda outras pessoas.

Na minha opinião, uma coisa muito importante que muitas pessoas que têm ambições de contribuir para as pessoas de código aberto ignoram é a comunicação com os outros desenvolvedores do projeto de código aberto.

Se você deseja contribuir para um projeto de código aberto, a primeira coisa a fazer é seguir o que está acontecendo no projeto. Se houver uma lista de discussão, fórum, Grupo do Google ou outra maneira pela qual os desenvolvedores se comunicam, participe. Descubra quais contribuições são mais necessárias. Faça perguntas sobre como o software funciona, etc.

Se você acabou de baixar o código-fonte, tente entendê-lo sozinho, pois isso lhe custará muito mais tempo. Se você conserta algo ou adiciona um novo recurso e o apresenta repentinamente, é menos provável que seja aceito.

Então, converse com outros desenvolvedores, descubra quais são os bugs de maior prioridade ou os recursos ausentes, etc.

Eu até passei por alguns arquivos no código-fonte que baixei, mas não entendi nada.

Este é o primeiro bug que você deve corrigir. Você precisa entender a base de código antes de começar a corrigir os erros. Caso contrário, como você saberá se suas correções quebrarão mais alguma coisa?

Existem diferentes métodos para se familiarizar com o código em um projeto ao qual você está ingressando. Meu método favorito é ler todo o código uma vez e depois voltar e examinar as seções com mais detalhes.