Contribuir a Qiskit

Qiskit es un proyecto de código abierto comprometido a llevar la computación cuántica a personas de cualquier perfil de conocimiento. Esta página describe cómo puedes unirte a la comunidad de Qiskit para lograr este objetivo.

Antes de que Empieces

Si eres nuevo en la contribución de Qiskit, te recomendamos que hagas lo siguiente antes de sumergirte en el código:

1. Lee el Código de Conducta

2. Lee las Pautas de Contribución específicas del repositorio para el cual has decidido contribuir.

3. Configura tu entorno de desarrollo

4. Familiarízate con la comunidad Qiskit (a través de Slack, Stack Exchange, GitHub etc.)

Contribuir a un Repositorio Específico

Cada paquete de Qiskit tiene su propio conjunto de Pautas de Contribución (guardadas en el archivo CONTRIBUTING.md) que detalla información específica sobre cómo contribuir a ese repositorio. Asegúrate de leer las Pautas de Contribución específicas del repositorio antes de realizar tu contribución a un repositorio específico, ya que cada proyecto puede tener requerimientos y procesos ligeramente diferentes. Para Qiskit Terra, el repositorio principal, las pautas de contribución se pueden encontrar aquí. Otros paquetes de Qiskit que pueden recibir contribuciones se pueden encontrar como repositorios separados en el Github de Qiskit oficial.

Configura Tu Entorno de Desarrollo

Para comenzar a contribuir con los repositorios de Qiskit basados en Python, deberás configurar un Entorno de Desarrollo Virtual de Python e instalar el paquete apropiado desde el código fuente.

Para obtener una guía rápida sobre cómo hacer esto para qiskit-terra, echa un vistazo al video de YouTube How to Install Qiskit - Contributors.

Para los paquetes que no son de Python, debes consultar el archivo CONTRIBUTING.md para obtener detalles específicos sobre la configuración de tu entorno de desarrollo.

Configurar el Entorno de Desarrollo Virtual de Python

Los entornos virtuales (virtual environments) son usados en el desarrollo en Qiskit para aislar el ambiente de desarrollo de los paquetes del sistema en general. De esta manera podemos evitar ser dependientes de que nuestro sistema tenga una configuración específica. Para desarrolladores, esto también hace que sea fácil mantener múltiples entornos (por ejemplo, uno por cada versión compatible de Python, para versiones anteriores de Qiskit, etc.).

Python venv

Todas las versiones de Python compatibles con Qiskit incluyen el módulo de entorno virtual incorporado venv.

Comienza creando un nuevo entorno virtual con venv. El entorno resultante utilizará la misma versión de Python que lo creó y no heredará los paquetes instalados para todo el sistema por defecto. La carpeta especificada se creará y se utilizará para contener la instalación del entorno. Se puede colocar en cualquier lugar. Para más detalles, consulta la documentación oficial de Python, Creación de entornos virtuales.

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

Activa el entorno invocando el script de activación correspondiente a tu sistema, encontrado en la carpeta del entorno. Por ejemplo, para bash/zsh:

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

Actualiza pip dentro del entorno para asegurarte de que las dependencias de Qiskit instaladas en las siguientes secciones puedan ser ubicadas en tu sistema.

pip install -U pip

Conda

Para los usuarios de Conda, se puede crear un nuevo entorno de la siguiente manera.

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

pip install -e .

Pull Requests

Utilizamos pull requests de Github para aceptar las contribuciones.

Aunque no es obligatorio, abrir una nueva incidencia sobre el error que estás arreglando o la funcionalidad en la que estás trabajando antes de abrir un Pull Request, es un paso importante para iniciar una discusión con la comunidad sobre tu trabajo. La incidencia nos da un lugar para hablar sobre la idea y cómo podemos trabajar juntos para implementarla en el código. También le permite a la comunidad saber en qué estás trabajando y, si necesitas ayuda, puedes hacer referencia a la incidencia cuando lo discutas con otros miembros de la comunidad y del equipo.

Si has escrito algo de código, pero necesitas ayuda para terminarlo, o deseas obtener comentarios iniciales sobre él antes de finalizarlo, o deseas compartirlo y discutirlo antes de concluir la implementación, puedes abrir un Pull Request como Draft (Borrador) e inicia el título con la etiqueta [WIP] (para Work In Progress). Esto indicará a los revisores que el código en el PR (Pull Request) no está en su estado final y cambiará. También significa que no se integrará el código hasta que esté finalizado. Tú o un revisor pueden eliminar la etiqueta [WIP] cuando el código esté listo para ser revisado por completo para su integración.

Antes de marcar tu Pull Request como «listo para revisión», asegúrate de haber seguido la Lista de Verificación de PR a continuación. Los PR que se adhieren a esta lista tienen más probabilidades de ser revisados y fusionados de manera oportuna.

Lista de Verificación del Pull Request:

• Has seguido los requerimientos del archivo CONTRIBUTING.md para el repositorio específico al que estás contribuyendo.

• Todas las comprobaciones de CI pasan (se recomienda ejecutar pruebas y comprobaciones lint localmente antes de enviar).

• Se han agregado nuevas pruebas para cualquier nueva funcionalidad que se haya introducido.

• La documentación se ha actualizado en consecuencia para cualquier funcionalidad nueva/modificada.

• Se ha agregado una nota de la versión si el cambio tiene un impacto en el usuario.

• Se han eliminado todos los comentarios superfluos o declaraciones de impresión.

• Todos los colaboradores han firmado el Acuerdo de Licencia del Contribuidor.

• El PR tiene un título conciso y explicativo (por ejemplo, Fixes Issue1234 ¡es un mal título!).

• Si el PR aborda un problema abierto, la descripción del PR incluye la sintaxis fixes #issue-number para vincular el PR a ese problema (debes usar la redacción exacta para que GitHub cierre automáticamente el problema cuando el PR sea fusionado)

Revisión de Código

La revisión del código se realiza de forma abierta y está disponible a cualquier persona. Si bien solo los mantenedores tienen acceso a las confirmaciones de fusión, los comentarios de la comunidad sobre los pull requests son extremadamente valiosos. También es un buen mecanismo para aprender sobre el código base.

Los tiempos de respuesta pueden variar para tu PR, no es inusual esperar algunas semanas para que un mantenedor revise tu trabajo, debido a otros compromisos internos. Si has estado esperando más de una semana por una revisión de tu PR, no dudes en etiquetar al mantenedor correspondiente en un comentario para recordarle cortésmente que revise tu trabajo.

¡Por favor sé paciente! Los mantenedores tienen otras prioridades en las que centrarse, por lo que tu trabajo puede tardar un tiempo en revisarse y fusionarse. Los PR que están en buena forma (es decir, siguiendo la Lista de Verificación del Pull Request:) son más fáciles de revisar para los mantenedores y es más probable que se fusionen de manera oportuna. También asegúrate de ser siempre amable y respetuoso en sus interacciones con los mantenedores y otros colaboradores, puedes leer el Código de Conducta de Qiskit.

Acuerdo de Licencia del Contribuidor

Antes de que puedas enviar cualquier código, todos los colaboradores deben firmar un acuerdo de licencia de contribuidor (contributor license agreement, CLA). Al firmar un CLA, atestiguas que eres el autor de la contribución y que estás contribuyendo libremente bajo los términos de la licencia Apache-2.0.

Cuando contribuyas al proyecto de Qiskit con un nuevo Pull Request, un bot evaluará si has firmado el CLA. Si es necesario, el bot comentará sobre el Pull Request, incluyendo un enlace para aceptar el acuerdo. El documento CLA individual está disponible para su revisión en formato PDF.

Nota

Si tu contribución es parte de tu empleo o tu contribución es propiedad de tu empleador, entonces seguramente necesitas firmar también un CLA corporativo y enviarlo al correo <qiskit@us.ibm.com>.