개발 프로세스

개요

코드와 문서에 대한 모든 변경 사항은 프로젝트에 대한 풀 리퀘스트를 통해 제출해야 합니다. 프로젝트의 GitHub 리포지토리에 풀 리퀘스트를 통해 제출해야 합니다.

대부분의 프로젝트에는 해당 프로젝트 또는 특정 유형의 기여에 대한 세부 정보가 포함된 전용 기여 가이드가 또는 특정 유형의 기여에 대한 세부 정보가 포함된 전용 기여 가이드가 있습니다. 이 문서 는 문서 읽기에서 찾을 수 있습니다. 예를 들어, Briefcase의 문서에는 두 가지 유형의 기여 가이드와 코드 와 문서.

모든 제출물은 BeeWare 행동 규범](/커뮤니티/행동 규범)을 준수해야 합니다. 행동 규범을 준수해야 합니다.

변경 노트

브리프케이스와 토가를 비롯한 여러 BeeWare 프로젝트에서는 각 프로젝트마다 풀 리퀘스트는 변경 노트와 함께 제출해야 합니다. 이러한 변경 노트는 프로젝트의 새 릴리스가 커팅될 때 함께 컴파일되어 새 릴리즈에 대한 릴리즈 노트를 생성합니다.

BeeWare는 Towncrier를 사용하여 다음을 수행합니다. 변경 노트를 관리합니다.

변경 노트 파일은 changes 디렉터리에 생성하고 이 형식을 사용하여 이름을 지정해야 합니다:

<PR/이슈 #>.<변경 유형>.rst

예를 들어, GitHub 이슈 #42를 수정하는 풀 리퀘스트의 이름은 42.bugfix.rst`. 풀 리퀘스트가 특정 이슈와 연관되지 않은 경우 이슈와 연관되지 않은 경우에는 풀 리퀘스트 번호를 대신 사용할 수 있습니다. 다음과 같이 해야 할 수 있습니다. 풀 리퀘스트를 받기 위해 변경 노트 없이 풀 리퀘스트를 만든 다음 번호를 할당받은 다음, 변경 노트가 포함된 업데이트를 푸시하고 변경 노트가 포함된 업데이트를 푸시해야 합니다.

변경 노트의 변경 유형은 다음 중 하나이어야 합니다:

기능
bugfix
doc
removal
misc

'기타' 유형은 사용자에게 영향을 주지 않는 변경을 위해 예약되어 있으며 릴리스 노트에 기록할 필요가 없습니다. 사소한 오타 수정 문서에서 사소한 오타 수정, CI 구성 업데이트 및 버그 수정 아직 공식적으로 릴리스되지 않은 기능의 예는 다음과 같습니다. 기타` 마커를 사용하여 설명할 수 있는 기능의 예입니다.

변경 노트는 한 줄의 텍스트로 작성해야 하며, 사용자의 관점에서 변경 사항에 대한 높은 수준의 깊은 기술 설명이나 구현 세부 사항이 아닌 사용자 관점에서 변경 사항을 요약한 기술적인 설명이나 구현 세부 사항이 아닙니다. 변경 노트는 커밋 메시지와 구별됩니다. 커밋 메시지는 어떤 작업이 수행되었는지를 설명하므로 향후 개발자가 변경 이유를 따라갈 수 있도록 설명합니다. 변경 노트 는 "사용자를 대상으로 하는" 설명으로, 변경으로 인해 사용할 수 있는 새로운 기능에 대해 의 관점에서 설명하는 "사용자 대면" 설명입니다. 변경 노트를 변경 노트를 변경 사항을 알리는 보도 자료로 생각하는 것이 도움이 될 수 있습니다. 커밋 설명.

예를 들어, 날짜 처리로 인한 버그를 수정하는 경우 커밋 메시지 또는 풀 리퀘스트 설명이 표시될 수 있습니다:

날짜 위젯 유효성 검사에 MM-DD-YYYY 형식 유효성 검사기를 추가했습니다. 체인에 추가했습니다.

구현에 적용된 변경 사항을 자세히 설명합니다. 코드를 검토하는 사람에게 도움이 될 것입니다. 그러나 해당 변경 노트는 다음과 같이 표시될 수 있습니다:

날짜 위젯은 이제 미국 형식의 날짜를 사용할 수 있습니다.

최종 사용자가 경험하게 될 기능적 변화를 설명합니다. 사용자가 경험하게 될 기능적 변화를 설명합니다. 사용자는 구현에 대해 아무것도 몰라도 이 설명을 읽을 수 있습니다. 아무것도 몰라도 이 설명을 읽을 수 있습니다.

코드 스타일

BeeWare의 프로젝트는 사전 커밋을 사용하여 자동화합니다. 코드 스타일 준수를 자동화합니다. 이러한 검사는 각 저장소의 '.pre-commit-config.yaml' 파일에 정의되며 자동으로 풀 리퀘스트가 열릴 때 CI에서 자동으로 실행됩니다. 가 열리면 자동으로 실행된다.

로컬 개발 환경에서 커밋 전 검사를 자동화하려면 각 git 커밋과 함께 pre-commit install을 실행합니다.

포함된 사전 커밋 확인:

검정은 다음을 보장합니다. 균일한 코드 서식
docformatter는 문서 문자열과 주석의 균일한 서식을 보장합니다.
파이업그레이드](https://github.com/asottile/pyupgrade)는 코드가 파이썬의 최신 모범 사례를 사용하도록 합니다.
isort](https://pycqa.github.io/isort/) 균일한 `import' 문을 균일하게 만듭니다
flake8](https://flake8.pycqa.org/en/latest/) 일반적인 코딩과 구문 문제를 확인합니다. 및 구문 문제 확인
TOML 파일과 같은 구조화된 문서의 유효성을 검사하는 기타 검사 및 불필요한 공백 제거

추가 가이드라인:

댓글에 '우리'를 사용하지 않도록 하세요(예: "우리는 반복합니다"가 아닌 "반복합니다. over"
변수, 함수 및 메서드에는 대/소문자가 아닌 밑줄을 사용합니다. 이름
클래스 이름(또는 클래스를 반환하는 팩토리 함수의 경우 클래스를 반환하는 팩토리 함수)

스핑크스 스타일 독스트링과 257 사용, 484를 사용한 유형 주석은 선택 사항이지만 권장됩니다.

예를 들어

def function_name(param1: int, param2: str) -> bool:
    """타입과 독스트링이 있는 함수 예제입니다.

    :파라미터 파라미터1: 첫 번째 매개변수입니다.
    :param param2: 두 번째 파라미터.

    :반환합니다: 반환 값입니다. 성공하면 참, 그렇지 않으면 거짓입니다.
    """

테스트 문서 문자열에 각 테스트가 보여줄 것으로 예상되는 동작을 명시합니다. 가 보여줄 예상 동작을 명시하세요. "다음을 테스트합니다" 또는 "다음을 보장합니다" 등의 프리앰블은 포함하지 마세요. 그" 등의 전치사를 포함하지 마세요.
티켓에 다음과 같은 애매한 문제가 있는 경우 티켓 참조를 예약합니다. 문서 문자열이나 댓글에 추가하세요. 다음과 같이 문장 끝에 티켓 번호를 포함하세요. this:
```
def test_foo():
    """테스트 문서 문자열은 다음과 같습니다(#123456)."""
```
달리 명시되지 않는 한, 8을 따르십시오('8'에 주의하여 섹션 2를 참고하세요.)