통합 수정 사항을 제출하는 방법

툴킷 커뮤니티의 아낌 없는 참여를 환영합니다! 버그의 잠재적 픽스를 발견했거나 툴킷에 포함되어야 한다고 생각하는 기능을 구현했다면 아래 가이드라인에 따라 적절한 채널을 통해 전송해 주시기 바랍니다.

연락 주십시오

개발하거나 해결하고 싶은 사항이 있다면 알려 주십시오. 여러분이 올바른 방향으로 나아가고 불필요한 작업에 얽매이지 않도록 필요한 정보를 제공해 드릴 수 있습니다. 무엇보다 사용자 여러분이 빌드하고 싶은 것이 무엇인지, 툴킷을 어떻게 사용하고 있는지, 툴킷을 어떻게 하면 더 멋지게 만들 수 있을지 이야기를 나누고 싶습니다.

Github에서 리포지토리 포크(fork)

대부분의 툴킷 엔진, 앱, 프레임워크 코드는 Github에서 공개적으로 개발됩니다. 수정 중인 리포지토리를 Github에서 로컬 환경으로 포크(fork)하십시오.

변경 작업

개발 작업을 분기에서 로컬로 진행하고, 자체 환경에서 제출 준비가 되었다는 확신이 들 때까지 테스트하십시오. 기존 코드 베이스의 스타일과 맞추고 목적에 맞게 변경하십시오. 예를 들어, 코드 행 3개에서 버그를 수정하는 중이라면 파일 전체에서 공백 문제를 수정하려고 하지 마십시오. 그렇게 하면 툴킷 그렘린들이 화를 냅니다.

코멘트!

어떤 작업을 하는 중인지, 왜 하는지 자세한 코멘트를 추가하십시오. 나중에 여러분 같은 누군가가 이 리포지토리를 포크(fork)할 수 있고, 그 사람도 여러분의 코드의 목적과 그 이유를 이해해야 한다는 사실을 기억해 두시기 바랍니다. 그렇다고 해서 과한 코멘트를 남기지는 마십시오. :)

테스트

다른 사용자들은 매우 다양한 환경과 변수를 가지고 있고, 그 환경과 변수가 여러분이 스튜디오에 보유하고 있는 것과 일치하지 않을 수 있다는 점을 기억해 두십시오. 툴킷은 이러한 일들이 사용자에게 미치는 영향을 최소화하려고 하지만 언제나 그렇듯 다른 사용자들의 환경에는 서로 다른 점이 존재할 수 있습니다. 예:

코드가 OS X, Windows, Linux에서 동일하게 작동합니까?
지원되는 모든 소프트웨어 버전에서 작동합니까?
사용자가 터미널, SG 데스크톱, ShotGrid 또는 자체 커스텀 앱 중 어디에서 실행하든 항상 동일하게 작동합니까?

사용자 요청 생성

준비가 되면 변경 사항을 Github로 다시 푸시하고 사용자 요청을 생성하십시오. 사용자 요청은 코드가 무슨 기능을 하는지, 왜 변경이 필요한지 등에 관해 자세한 내용을 담고 있어야 합니다. 풀 리퀘스트를 작성할 때에는 이 영역의 코드에 관해 지식이 거의 없는 사용자를 염두에 두고 작성해야 합니다. 사용자 요청은 누구든 공개적으로 볼 수 있기 때문에 다른 사용자들도 쉽게 이해할 수 있도록 설명을 자세하게 잘 써놓으면 좋습니다!

그 다음은?

시간 여유가 되면 여러분들의 요청을 검토합니다. 코드 또는 사용 사례에 관해 의견을 남기고, 궁금한 점에 답변도 달아 드립니다. 요청을 반송해 변경을 요청할 수도 있습니다. 기분 나쁘게 해드릴 의도는 전혀 없습니다! 여러분의 참여와 헌신에 항상 감사하며 일이 진행되는 방식도 잘 이해하고 있습니다. 매일 코드를 접하다 보니 모든 사람이 완벽한 코드를 제출할 수 없다는 점도 잘 알고 있습니다.

검토를 마친 후에 사용자 요청을 수락하는 경우에는 QA 대기열에 올리고, 그러면 리포지토리에 병합되어 적절한 시점에 릴리즈됩니다. 타임라인은 여러 요인에 따라 달라질 수 있으니 이해해 주시기 바랍니다.

사용자 요청을 정중히 거절할 수도 있습니다. 역시 기분 나쁘게 생각하지 않으셨으면 좋겠습니다. 여러분의 노고와 기여에 항상 감사하고 있습니다. 거절 요인은 여러 가지일 수 있습니다. 하지만 위의 가이드라인을 잘 지킨다면 거절될 가능성도 거의 없습니다.