Contribuindo para o Qiskit#

O Qiskit é um projeto de código aberto comprometido em introduzir a computação quântica para pessoas com qualquer tipo de experiência e conhecimento em TI. Esta página descreve como você pode se juntar à comunidade Qiskit neste objetivo.

Antes de começar#

Se você é um novo contribuidor do Qiskit, recomendamos que faça o seguinte antes de mergulhar no código:

  1. Leia o Código de conduta

  2. Leia as especificações do repositório Orientações de contribuição, do repositório que decidir contribuir.

  3. Configurando seu ambiente de desenvolvimento

  4. Entre em contato com a comunidade Qiskit (via Slack, Stack Exchange, GitHub etc.)

Contribuindo em um Repo Específico#

Cada pacote Qiskit tem seu próprio conjunto de Diretrizes de Contribuição (mantido no arquivo CONTRIBUTING.md) que detalha informações específicas sobre como contribuir para esse repositório. Certifique-se de ler as Diretrizes de contribuição específicas do repositório antes de fazer sua contribuição para um repositório específico, pois cada projeto pode ter requisitos e processos ligeiramente diferentes. Para Qiskit Terra, o repositório principal, as diretrizes de contribuição podem ser encontradas aqui. Outros pacotes Qiskit que podem receber contribuições podem ser encontrados como repositórios separados no site oficial Qiskit Github.

Configurando seu ambiente de densenvolvimento#

Para começar a contribuir com os reposítórios Qiskit baseados em Python, você precisará configurar um ambiente de desenvolvimento virtual Python, e instalar os pacotes específicos da fonte.

Para um guia rápido sobre como fazer isto para qiskit-terra, siga o vídeo Como instalar Qiskit-Contributors no Youtube.

Para pacotes não em python, você deve verificar o arquivo CONTRIBUTING.md para detalhes específicos para configurar seu ambiente de desenvolvimento.

Configurar o Ambiente Virtual de Desensenvolvimento Python#

Os ambientes virtuais são usados para desenvolvimento com o Qiskit para isolar o ambiente de desenvolvimento dos pacotes de todo o sistema. Desta forma, evitamos nos tornar inadvertidamente dependentes de uma configuração de sistema específica. Para desenvolvedores, isso também facilita a manutenção de vários ambientes (por exemplo, um por versão do Python suportada, para versões mais antigas do Qiskit, etc.).

Todas as versões do Python suportadas pelo Qiskit incluem o módulo de ambiente virtual integrado venv.

Comece criando um novo ambiente virtual com o comando venv. O ambiente gerado usará a mesma versão do Python usada em sua criação, e não irá herdar, por padrão, os pacotes instalados no sistema. O diretório especificado será criado e utilizado para armazenar a instalação do ambiente, podendo ser movido para qualquer lugar. Para mais informações, veja a documentação oficial do Python, Criação de ambientes virtuals.

python3 -m venv ~/.venvs/qiskit-dev

Ative o ambiente usando o script específico de seu sistema, que pode ser encontrado na pasta do ambiente. Por exemplo, para bash/zsh:

source ~/.venvs/qiskit-dev/bin/activate

Atualize o pip dentro do ambiente para garantir que as dependências do Qiskit instaladas nas próximas seções possam ser localizadas pelo seu sistema.

pip install -U pip

Para usuários do Conda, um novo ambiente pode ser criado da seguinte forma.

conda create -y -n QiskitDevenv python=3
conda activate QiskitDevenv

pip install -e .

Pull Requests#

Utilizamos GitHub pull requests para aceitar contribuições.

Embora não seja obrigatório, é recomendável abrir uma nova issue sobre o bug que você está consertando, ou o recurso em que está trabalhando antes de abrir um pull request. A issue nos proporciona um espaço para iniciar uma discussão com a comunidade sobre o seu trabalho, falar sobre a ideia e como podemos trabalhar juntos para implementá-la no código. Também permite a comunidade saber no que você está trabalhando, e se precisar de ajuda, é possível referencia-lá ao discutir com outros membros da comunidade e da equipe.

Se já escreveu algum código mas precisa de ajuda para finaliza-lo, deseja receber feedback inicial, ou mesmo compartilha-lo antes de finalizar sua implementação, você pode abrir um Draft pull request e adicionar, antes do título, a tag [WIP] (Work In Progress). Isso irá indicar aos revisores que o código no PR ainda não está finalizado e receberá mudanças. Também significa que não iremos mergear o commit até que este seja finalizado. Você ou um revisor pode remover a [WIP] tag quando o código estiver pronto para ser revisado completamente e habilitado para merge.

Antes the marcar seu Pull Request como «pronto para revisão», assegure-se de ter seguido a checklist de PR abaixo. PRs que seguem esta lista são muito mais prováveis de terem revisão e merge em um tempo adequado.

Pull Request Checklist:#

  • Você seguiu os requerimentos no arquivo CONTRIBUTING.md para o repositório em que está contribuindo.

  • Todas as verificações de CI passam (é recomendado rodar os testes e checar o lint localmente antes de dar push).

  • Novos testes foram adicionados para cada nova funcionalidade introduzida.

  • A documentação foi atualizada de acordo com as novas/modificadas funcionalidades.

  • Uma nota de lançamento foi adicionada caso as mudanças tenham impacto para os usuários.

  • Qualquer comentário supérfluo, ou impressões na tela foram removidos.

  • Todos os contribuidores assinaram a Acordo de Licença do Contribuidor.

  • O PR tem um título conciso e autoexplicativo (e.g. Fixes Issue1234 é um título ruim!).

  • Caso o PR foque em um issue em aberto, a descrição incluí a sintaxe fixes #issue-number para ligar o PR ao issue em questão (você precisa usar exatamente a mesma descrição para que o GitHub feche automaticamente o issue após o merge)

Revisão de Código#

A revisão do códiogo é feita de forma aberta e é acessível para todos. Mesmo que apenas mantenedores possam fazer o merge, o feedback da comunidade nos pull requests é extremamente valioso. É, também, um ótimo mecanismo para aprender mais sobre a base de código.

O tempo de resposta para seu PR pode variar, não é incomum esperar algumas semanas para que os mantenedores revisem seu trabalho, visto que possuem outras tarefas internas. Caso esteja esperando por mais de uma semana pela revisão de seu PR, sinta-se livre para mencionar um mantenedor relevante em um comentário, gentilmente lembrando-o sobre a revisão do seu seu trabalho.

Por favor, seja paciente! Mantenedores possuem diversas outras prioridades para focar, com isto, pode levar um tempo para a revisão e merge. PRs que possuem uma boa estrutura (i.e seguem a Pull Request Checklist:) são mais fáceis para mantenedores revisarem, e mais prováveis de terem merge mais rápido. Por favor, assegur-se de sempre ser gentil e respeitoso em suas interações com mantendores e outros contribuidores, leia o Código de Conduta Qiskit.

Acordo de Licença do Contribuidor#

Antes de poder enviar qualquer código, todos os colaboradores devem assinar o acordo de licença do contribuidor (contributor license agreement - CLA). Ao assinar um CLA, você está atestando que é o autor da contribuição, e que está contribuindo livremente nos termos da licença Apache-2.0.

Quando você contribuir para o projeto Qiskit com uma nova solicitação de pull, um bot irá avaliar se você assinou o CLA. Se necessário, o bot irá se pronunciar sobre a solicitação de pull, incluindo um link para aceite o acordo. O documento individual CLA está disponível para revisão como PDF.

Nota

Se a sua contribuição faz parte do seu emprego ou a sua contribuição é propriedade do seu empregador, então é muito provável que você precise assinar também um CLA corporativo e o envie para nós em <qiskit@us.ibm.com>.