관리자 가이드

이 문서는 관리자 를 병합 권한을 가진 기여자로 정의한다. 여기에 자세히 설명된 정보는 주로 Qiskit 배포 및 기타 내부 과정과 관련된 것이다.

안정된 브랜치 정책

안정된 브랜치는 배포 후 마스터에서 수정된 심각한 버그 및 보안 이슈에 대한 안전한 소스를 유지하는 것을 목표로 한다. 안정된 브랜치의 PR을 검토할 땐, 주어진 패치의 위험과 안정된 브랜치의 사용자에게 제공할 가치 사이의 균형을 맞춰야 한다. 안정된 브랜치에는 한정된 클래스의 변경만 포함하는 것이 적절하다. 상당히 모호한 오류 처리 사례에 대한 사소한 수정과 같이, 주요 이슈에 대한 크고 위험한 패치가 유효한 경우도 있다. 변경을 고려할 때, 다음과 같은 여러 요소를 고려해야 한다:

• 회귀의 위험: 아주 작은 변경도 무언가를 망가트릴 위험이 있으며, 안정된 브랜치에서는 최대한 회귀를 제고하고자 한다.

• 사용자 가시성 이점: 사용자가 실제로 알아차릴 만한 것을 수정하는가? 그렇다면 그것은 얼마나 중요한가?

• 수정이 얼마나 자립적인가: 중요한 문제를 해결하지만 동시에 많은 코드를 변경하는 경우, 덜 위험한 수정은 어떤 모습일지 생각해볼 가치가 있다.

• 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.

문서 구조

The way documentation is structured in Qiskit is to push as much of the actual documentation into the docstrings as possible. This makes it easier for additions and corrections to be made during development, because the majority of the documentation lives near the code being changed.

Refer to https://qiskit.github.io/qiskit_sphinx_theme/apidocs/index.html for how to create and write effective API documentation, such as setting up the RST files and docstrings.