의미 체계 커널에 기여

아티클
11/03/2024

문제를 제출하고, 토론을 시작하고, PR(끌어오기 요청)을 제출하여 의미 체계 커널에 기여할 수 있습니다. 코드를 기여하는 것은 매우 감사하지만, 발생하는 문제에 대한 문제를 단순히 신고하는 것만으로도 노력을 집중하는 데 도움이 되므로 기여할 수 있는 좋은 방법입니다.

문제점 및 의견 보고

버그 보고서, API 제안 및 전반적인 피드백을 항상 환영합니다. GitHub를 사용하므로 문제 및 토론 탭을 사용하여 팀과 대화를 시작할 수 있습니다. 다음은 가능한 한 빨리 피드백에 응답할 수 있도록 문제 및 피드백을 제출할 때 몇 가지 팁입니다.

문제 보고

SDK에 대한 새 문제는 문제 목록에서 보고할 수 있지만 새 문제를 제출하기 전에 문제 목록을 검색하여 아직 존재하지 않는지 확인하세요. 의미 체계 커널 설명서(이 사이트)에 문제가 있는 경우 의미 체계 커널 설명서 리포지토리에 문제를 제출하세요.

보고하려는 내용에 대한 기존 문제가 발견되면 토론에 사용자 고유의 피드백을 포함하세요. 또한 백로그에서 인기 있는 문제의 우선 순위를 지정하는 데 도움이 되도록 원래 게시물을 업보팅(👍 반응)하는 것이 좋습니다.

좋은 버그 보고서 작성

좋은 버그 보고서를 사용하면 유지 관리자가 기본 문제를 보다 쉽게 확인하고 근본 원인을 파악할 수 있습니다. 버그 보고서가 좋을수록 문제를 더 빠르게 해결할 수 있습니다. 이상적으로 버그 보고서에는 다음 정보가 포함되어야 합니다.

문제에 대한 개략적인 설명입니다.
최소한의 재현, 즉 잘못된 동작을 재현하는 데 필요한 코드/구성의 최소 크기입니다.
관찰된 실제 동작과 대조되는 예상 동작에 대한 설명입니다.
환경에 대한 정보: OS/배포, CPU 아키텍처, SDK 버전 등
추가 정보(예: 이전 버전의 회귀인가요? 알려진 해결 방법이 있나요?

문제 만들기

피드백 제출

의미 체계 커널에 대한 일반적인 피드백이나 더 나은 커널을 만드는 방법에 대한 아이디어가 있는 경우 토론 게시판에 공유하세요. 새 토론을 시작하기 전에 토론 목록을 검색하여 아직 존재하지 않는지 확인하세요.

공유하려는 특정 아이디어가 있는 경우 아이디어 범주를 사용하고 의미 체계 커널에 대한 질문이 있는 경우 Q&A 범주를 사용하는 것이 좋습니다.

또한 의미 체계 커널 디스코드 서버에 가입하여 Discord 커뮤니티에서 토론을 시작하고 만든 피드백을 공유할 수 있습니다.

토론 시작

피드백의 우선 순위를 지정하는 데 도움이 되도록 지원

현재 백로그의 문제 및 기능의 우선 순위를 지정하는 데 도움이 되도록 up-vote를 사용하므로 해결하려는 문제 또는 토론에 투표하세요.

다른 사용자가 기능의 혜택을 누릴 수 있다고 생각되면 다른 사용자에게 이 문제에 대해 투표하도록 요청하는 것이 좋습니다. 이렇게 하면 대부분의 사용자에게 영향을 주는 문제의 우선 순위를 지정할 수 있습니다. 문제 또는 토론에 대한 링크를 공유하여 동료, 친구 또는 Discord 의 커뮤니티에 문제를 투표하도록 요청할 수 있습니다.

끌어오기 요청 제출

의미 체계 커널에 대한 기여를 환영합니다. 버그 수정 또는 기여하려는 새 기능이 있는 경우 아래 단계에 따라 PR(끌어오기 요청)을 제출하세요. 나중에 프로젝트 유지 관리자가 코드 변경 내용을 검토하고 수락되면 병합합니다.

권장 기여 워크플로

의미 체계 커널에 기여하려면 다음 워크플로를 사용하는 것이 좋습니다(의미 체계 커널 팀에서 사용하는 것과 동일한 워크플로).

작업에 대한 문제를 만듭니다.
- 사소한 변경은 이 단계를 건너뛸 수 있습니다.
- 토픽에 기존 문제가 있는 경우 다시 사용하세요.
- 제안 된 변경이 문제의 토론을 사용하여 좋은 것이라는 팀과 커뮤니티의 동의를 얻습니다.
- 구현 시 수행할 문제에 대해 명확하게 명시합니다. 이렇게 하면 문제를 사용자에게 할당할 수 있으며 다른 사용자가 실수로 문제를 해결할 수 없습니다.
GitHub에서 리포지토리의 개인 포크를 만듭니다(아직 없는 경우).
포크에서 기본(git checkout -b mybranch)에서 분기를 만듭니다.
- "issue-123" 또는 "githubhandle-issue"와 같은 의도를 명확하게 전달하도록 분기 이름을 지정합니다.
분기를 변경하고 커밋합니다.
해당하는 경우 변경 내용에 해당하는 새 테스트를 추가합니다.
변경 내용을 사용하여 리포지토리를 빌드합니다.
- 빌드가 깨끗한지 확인합니다.
- 새 테스트를 포함하여 테스트가 모두 통과했는지 확인합니다.
리포지토리의 주 분기에 대해 PR을 만듭니다.
- 설명에 변경 내용이 해결되고 있는 문제 또는 개선 사항을 명시합니다.
- 모든 연속 통합 검사가 전달되고 있는지 확인합니다.
코드 유지 관리자의 변경 내용에 대한 피드백 또는 승인을 기다립니다.
영역 소유자가 로그오프하고 모든 검사가 녹색이면 PR이 병합됩니다.

기여하는 동안 Dos 및 Don'ts

다음은 가능한 한 빨리 변경 내용을 검토하고 병합하는 데 도움이 되도록 의미 체계 커널에 기여할 때 권장하는 Dos 및 Don'ts 목록입니다.

할 일:

표준 .NET 코딩 스타일 및 Python 코드 스타일을 따르세요.
일반적인 지침과 다른 경우 변경 중인 프로젝트 또는 파일의 현재 스타일에 우선 순위를 지정하세요.
새 기능을 추가할 때 테스트를 포함합니다. 버그를 수정할 때는 현재 동작이 어떻게 손상되었는지를 강조하는 테스트 추가부터 시작합니다.
토론의 초점을 유지하십시오 . 새 항목 또는 관련 토픽이 나올 때 토론을 함께 추적하는 것보다 새 문제를 만드는 것이 더 나은 경우가 많습니다.
구현할 문제에 대해 명확하게 명시합니다.
귀하의 기여에 대한 블로그 및 /또는 트윗을 수행!

주의 사항:

큰 끌어오기 요청으로 팀을 놀라게하지 마십시오. 기여자를 지원하기를 원하므로 많은 시간을 투자하기 전에 방향에 동의할 수 있도록 문제를 제출하고 토론을 시작하는 것이 좋습니다.
작성하지 않은 코드를 커밋하지 마세요. 의미 체계 커널에 추가하는 것이 적합하다고 생각되는 코드를 찾으면 계속하기 전에 문제를 제출하고 토론을 시작합니다.
라이선스 관련 파일 또는 헤더를 변경하는 PR을 제출하지 마세요. 문제가 있다고 생각되면 문제를 제기하면 기꺼이 논의해 드리겠습니다.
문제를 제출하고 팀과 먼저 논의하지 않고 새 API를 만들지 마세요 . 라이브러리에 새로운 공용 노출 영역을 추가하는 것은 큰 문제이며, 이를 올바르게 사용할 수 있도록 하고 싶습니다.

호환성이 손상되는 변경

기여는 API 서명 및 동작 호환성을 유지해야 합니다. 기존 코드를 중단하는 변경을 하려면 호환성이 손상되는 변경이 보장되는 경우 아이디어를 논의하거나 변경하는 문제를 제출하세요. 그렇지 않으면 호환성이 손상되는 변경 내용이 포함된 기여가 거부됩니다.

CI(연속 통합) 프로세스

CI(연속 통합) 시스템은 PR에 대해 필요한 빌드를 자동으로 수행하고 테스트를 실행합니다(로컬로 실행해야 하는 빌드 포함). PR을 병합하려면 먼저 빌드 및 테스트 실행을 정리해야 합니다.

어떤 이유로든 CI 빌드가 실패하면 PR 문제가 해결될 수 있도록 오류의 원인을 확인하는 데 사용할 수 있는 링크로 업데이트됩니다.

설명서에 기여

또한 의미 체계 커널 설명서 리포지토리에 대한 기여도 허용합니다.

다음을 통해 공유