Guía de Mantenedores#

Este documento define a un mantenedor como un colaborador con privilegios de fusión (merge). La información detallada aquí está relacionada principalmente con las liberaciones de Qiskit y otros procesos internos.

Política de Ramificación Estable#

La rama estable está destinada a ser una fuente segura de correcciones para errores de alto impacto y problemas de seguridad que se han solucionado en master desde su liberación. Al revisar un PR de rama estable, debemos equilibrar el riesgo de cualquier parche dado con el valor que proporcionará a los usuarios de la rama estable. Solo una clase limitada de cambios es apropiada para su inclusión en la rama estable. Un parche grande y arriesgado para un problema importante podría tener sentido, al igual que una solución trivial para un caso de manejo de errores bastante oscuro. Se deben tomar en cuenta varios factores al considerar un cambio:

  • El riesgo de regresión: incluso los cambios más pequeños conllevan algún riesgo de romper algo, y realmente queremos evitar regresiones en la rama estable.

  • El beneficio de visibilidad para el usuario: ¿estamos arreglando algo que los usuarios podrían notar? y, de ser así, ¿qué tan importante es?

  • Qué tan autónoma es la solución: si soluciona un problema importante, pero también refactoriza una gran cantidad de código, probablemente valga la pena pensar en cómo se vería una solución menos riesgosa.

  • Whether the fix is already on main: a change must be a backport of a change already merged onto master, unless the change simply does not make sense on master.

Backporting#

When a PR tagged with stable backport potential is merged, or when a merged PR is given that tag, the Mergify bot will open a PR to the current stable branch. You can review and merge this PR like normal.

Estructura de la Documentación#

La forma en que la documentación está estructurada en Qiskit es buscar tener la mayor cantidad de la documentación en docstrings como sea posible. Esto facilita que se realicen adiciones y correcciones durante el desarrollo, porque la mayoría de la documentación se encuentra cerca del código que se está modificando.

Consulta https://qiskit.github.io/qiskit_sphinx_theme/apidocs/index.html para obtener información sobre cómo crear y escribir documentación eficaz de API, como la configuración de archivos RST y docstrings.