New contributor and not sure what to do? Want to help but just don’t know how\nto get started? This is the section for you.
\n\nThis page contains more general advice on ways you can contribute to Django,\nand how to approach that.
\nIf you are looking for a reference on the details of making code contributions,\nsee the Writing code documentation.
\nStart with these steps to discover Django’s development process.
\nTriage tickets
\nIf an unreviewed ticket reports a bug, try and reproduce it. If you\ncan reproduce it and it seems valid, make a note that you confirmed the bug\nand accept the ticket. Make sure the ticket is filed under the correct\ncomponent area. Consider writing a patch that adds a test for the bug’s\nbehavior, even if you don’t fix the bug itself. See more at\nHow can I help with triaging?
\nLook for tickets that are accepted and review patches to build familiarity\nwith the codebase and the process
\nMark the appropriate flags if a patch needs docs or tests. Look through the\nchanges a patch makes, and keep an eye out for syntax that is incompatible\nwith older but still supported versions of Python. Run the tests and make sure they pass.\nWhere possible and relevant, try them out on a database other than SQLite.\nLeave comments and feedback!
\nKeep old patches up to date
\nOftentimes the codebase will change between a patch being submitted and the\ntime it gets reviewed. Make sure it still applies cleanly and functions as\nexpected. Updating a patch is both useful and important! See more on\nSubmitting patches.
\nWrite some documentation
\nDjango’s documentation is great but it can always be improved. Did you find\na typo? Do you think that something should be clarified? Go ahead and\nsuggest a documentation patch! See also the guide on\n문서 작성하기.
\n\nSign the Contributor License Agreement
\nThe code that you write belongs to you or your employer. If your\ncontribution is more than one or two lines of code, you need to sign the\nCLA. See the Contributor License Agreement FAQ for a more thorough\nexplanation.
\nAs a newcomer on a large project, it’s easy to experience frustration. Here’s\nsome advice to make your work on Django more useful and rewarding.
\nPick a subject area that you care about, that you are familiar with, or\nthat you want to learn about
\nYou don’t already have to be an expert on the area you want to work on; you\nbecome an expert through your ongoing contributions to the code.
\nAnalyze tickets’ context and history
\nTrac isn’t an absolute; the context is just as important as the words.\nWhen reading Trac, you need to take into account who says things, and when\nthey were said. Support for an idea two years ago doesn’t necessarily mean\nthat the idea will still have support. You also need to pay attention to who\nhasn’t spoken – for example, if an experienced contributor hasn’t been\nrecently involved in a discussion, then a ticket may not have the support\nrequired to get into Django.
\nStart small
\nIt’s easier to get feedback on a little issue than on a big one. See the\neasy pickings.
\nIf you’re going to engage in a big task, make sure that your idea has\nsupport first
\nThis means getting someone else to confirm that a bug is real before you fix\nthe issue, and ensuring that there’s consensus on a proposed feature before\nyou go implementing it.
\nBe bold! Leave feedback!
\nSometimes it can be scary to put your opinion out to the world and say “this\nticket is correct” or “this patch needs work”, but it’s the only way the\nproject moves forward. The contributions of the broad Django community\nultimately have a much greater impact than that of any one person. We can’t\ndo it without you!
\nErr on the side of caution when marking things Ready For Check-in
\nIf you’re really not certain if a ticket is ready, don’t mark it as\nsuch. Leave a comment instead, letting others know your thoughts. If you’re\nmostly certain, but not completely certain, you might also try asking on IRC\nto see if someone else can confirm your suspicions.
\nWait for feedback, and respond to feedback that you receive
\nFocus on one or two tickets, see them through from start to finish, and\nrepeat. The shotgun approach of taking on lots of tickets and letting some\nfall by the wayside ends up doing more harm than good.
\nBe rigorous
\nWhen we say “PEP 8, and must have docs and tests”, we mean it. If a patch\ndoesn’t have docs and tests, there had better be a good reason. Arguments\nlike “I couldn’t find any existing tests of this feature” don’t carry much\nweight–while it may be true, that means you have the extra-important job of\nwriting the very first tests for that feature, not that you get a pass from\nwriting tests altogether.
\nBe patient
\nIt’s not always easy for your ticket or your patch to be reviewed quickly.\nThis isn’t personal. There are a lot of tickets and pull requests to get\nthrough.
\nKeeping your patch up to date is important. Review the ticket on Trac to\nensure that the Needs tests, Needs documentation, and Patch needs\nimprovement flags are unchecked once you’ve addressed all review comments.
\nRemember that Django has an 8 month release cycle, so there’s plenty of time\nfor your patch to be reviewed.
\nFinally, a well-timed reminder can help. See contributing code FAQ for ideas here.
\n