# Django 5.2.9 문서

# 신규 기여자에 대한 조언

새로운 기여자인데 어떻게 해야 할지 모르겠어요? 돕고 싶지만 어떻게 시작해야 할지 모르겠다고요? 여기가 당신을 위한 섹션입니다.

일어나서 달리십시오!

장고에 처음 기고하는 경우 :doc:’/intro/contribution’ 튜토리얼에서 도구와 워크플로우에 대해 설명합니다.

이 페이지에는 장고에 기여할 수 있는 방법과 장고에 접근하는 방법에 대한 보다 일반적인 조언이 포함되어 있습니다.

코드 기여에 대한 세부 정보를 보려면 :doc:’/internals/committing/writing-code/index’ 문서를 참조하십시오.

## 첫걸음

장고의 개발 과정을 알아보려면 다음 단계부터 시작하십시오.

### Triage tickets

If an unreviewed ticket reports a bug, try and reproduce it. If you can reproduce it and it seems valid, make a note that you confirmed the bug and accept the ticket. Make sure the ticket is filed under the correct component area. Consider writing a patch that adds a test for the bug’s behavior, even if you don’t fix the bug itself. See more at How can I help with development?.

### Review patches of accepted tickets

This will help you build familiarity with the codebase and processes. Mark the appropriate flags if a patch needs docs or tests. Look through the changes a patch makes, and keep an eye out for syntax that is incompatible with older but still supported versions of Python. Run the tests and make sure they pass. Where possible and relevant, try them out on a database other than SQLite. Leave comments and feedback!

### Keep old patches up-to-date

Oftentimes the codebase will change between a patch being submitted and the time it gets reviewed. Make sure it still applies cleanly and functions as expected. Updating a patch is both useful and important! See more on Contribution checklist.

### Write some documentation

Django’s documentation is great but it can always be improved. Did you find a typo? Do you think that something should be clarified? Go ahead and suggest a documentation patch! See also the guide on 문서 작성하기.

참고

‘reports page’_에는 위에서 제안한 바와 같이 티켓을 분류하고 패치를 검토하는 데 유용한 몇 가지 트랙 쿼리에 대한 링크가 포함되어 있습니다.

### Sign the Contributor License Agreement

사용자가 작성하는 코드는 사용자 또는 사용자의 것입니다. 기여가 코드 한두 줄 이상이면 ‘CLA’에 서명해야 합니다. 자세한 설명은 기여자 사용권 계약 FAQ_를 참조하십시오.

## 가이드라인

큰 프로젝트에 새로 온 사람은 좌절감을 느끼기 쉽습니다. 여기 장고에 대한 여러분의 작업을 더 유용하고 보람 있게 만들기 위한 몇 가지 조언이 있습니다.

### Pick a subject area

This should be something that you care about, that you are familiar with or that you want to learn about. You don’t already have to be an expert on the area you want to work on; you become an expert through your ongoing contributions to the code.

### Analyze tickets’ context and history

트랙은 절대적인 것이 아닙니다. 문맥은 단어만큼 중요합니다. 트랙을 읽을 때, 여러분은 누가 어떤 말을 하는지, 언제 어떤 말을 했는지 고려해야 합니다. 2년 전 아이디어에 대한 지원이 반드시 그 아이디어가 여전히 지지를 받는다는 것을 의미하지는 않습니다. 여러분은 또한 누가 말을 하지 않았는지도 관심을 가질 필요가 있습니다. 예를 들어, 경험 많은 기여자가 최근에 토론에 참여하지 않았다면, 티켓은 장고에 들어가는 데 필요한 지원을 받지 못할 수도 있습니다.

### Start small

큰 문제보다 작은 문제에 대한 피드백을 받는 것이 더 쉽습니다. ‘쉬운 선택’을 참조하십시오.

### Confirm support before engaging in a big task

즉, 문제를 수정하기 전에 다른 사람이 버그가 실제인지 확인하도록 하고, 버그를 구현하기 전에 제안된 기능에 대한 합의가 있는지 확인하는 것입니다.

### Be bold! Leave feedback!

때때로 자신의 의견을 세상에 내놓고 “이 표는 정확하다”거나 “이 패치는 작업이 필요하다”고 말하는 것이 두려울 수 있지만, 이것은 프로젝트가 앞으로 나아갈 수 있는 유일한 방법입니다. 넓은 장고 공동체의 기여는 궁극적으로 한 사람의 기여보다 훨씬 더 큰 영향을 미칩니다. 여러분이 없이는 못 합니다!

### Be cautious when marking things “Ready For Check-in”

If you’re really not certain if a ticket is ready, don’t mark it as such. Leave a comment instead, letting others know your thoughts. If you’re mostly certain, but not completely certain, you might also try asking on the `#contributing-getting-started` channel in the Django Discord server to see if someone else can confirm your suspicions.

### Wait for feedback, and respond to feedback that you receive

티켓 한 장 또는 두 장에 집중하여 처음부터 끝까지 보고 반복합니다. 많은 표를 가지고 어떤 사람들은 도중에 넘어지게 하는 산탄총 같은 접근법은 결국 득보다 실이 더 많습니다.

### Be rigorous

When we say “PEP 8, and must have docs and tests”, we mean it. If a patch doesn’t have docs and tests, there had better be a good reason. Arguments like “I couldn’t find any existing tests of this feature” don’t carry much weight. While it may be true, that means you have the extra-important job of writing the very first tests for that feature, not that you get a pass from writing tests altogether.

### Be patient

티켓이나 패치가 빠르게 검토되는 것이 항상 쉬운 것은 아닙니다. 이건 개인적인 일이 아니에요. 통과하기 위해 많은 티켓과 풀 요청이 있습니다.

패치를 최신 상태로 유지하는 것이 중요합니다. 모든 검토 코멘트를 처리한 후 Trac에서 티켓을 검토하여 테스트 필요, 문서 필요 및 패치 개선 필요 플래그가 선택 취소되었는지 확인하십시오.

Remember that Django has an eight-month release cycle, so there’s plenty of time for your patch to be reviewed.

마지막으로, 적절한 시기에 상기시키는 것이 도움이 될 수 있습니다. 아이디어에 대한 자세한 내용은:ref:’코드 기여 FAQ’를 참조하십시오.