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 Contributing code documentation.
\nStart with these steps to discover Django’s development process.
\nIf an unreviewed ticket reports a bug, try and reproduce it. If you can\nreproduce it and it seems valid, make a note that you confirmed the bug and\naccept the ticket. Make sure the ticket is filed under the correct component\narea. Consider writing a patch that adds a test for the bug’s behavior, even if\nyou don’t fix the bug itself. See more at How can I help with development?.
\nThis will help you build familiarity with the codebase and processes. Mark the\nappropriate flags if a patch needs docs or tests. Look through the changes a\npatch makes, and keep an eye out for syntax that is incompatible with older but\nstill 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!
\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\nContribution checklist.
\nDjango’s documentation is great but it can always be improved. Did you find a\ntypo? Do you think that something should be clarified? Go ahead and suggest a\ndocumentation patch! See also the guide on\nWriting documentation.
\n\nThe code that you write belongs to you or your employer. If your contribution\nis more than one or two lines of code, you have the option to sign the CLA.\nSee the Contributor License Agreement FAQ for a more thorough explanation.
\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.
\nThis should be something that you care about, that you are familiar with or\nthat you want to learn about. You don’t already have to be an expert on the\narea you want to work on; you become an expert through your ongoing\ncontributions to the code.
\nTrac isn’t an absolute; the context is just as important as the words. When\nreading Trac, you need to take into account who says things, and when they were\nsaid. Support for an idea two years ago doesn’t necessarily mean that the idea\nwill still have support. You also need to pay attention to who hasn’t spoken\n– for example, if an experienced contributor hasn’t been recently involved in\na discussion, then a ticket may not have the support required to get into\nDjango.
\nIt’s easier to get feedback on a little issue than on a big one. See the\neasy pickings.
\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 you\ngo implementing it.
\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 do\nit without you!
\nIf you’re really not certain if a ticket is ready, don’t mark it as such. Leave\na comment instead, letting others know your thoughts. If you’re mostly certain,\nbut not completely certain, you might also try asking on the\n#contributing-getting-started channel in the Django Discord server to\nsee if someone else can confirm your suspicions.
Focus on one or two tickets, see them through from start to finish, and repeat.\nThe shotgun approach of taking on lots of tickets and letting some fall by the\nwayside ends up doing more harm than good.
\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 like\n“I couldn’t find any existing tests of this feature” don’t carry much weight.\nWhile it may be true, that means you have the extra-important job of writing\nthe very first tests for that feature, not that you get a pass from writing\ntests altogether.
\nIt’s not always easy for your ticket or your patch to be reviewed quickly. This\nisn’t personal. There are a lot of tickets and pull requests to get through.
\nKeeping your patch up to date is important. Review the ticket on Trac to ensure\nthat the Needs tests, Needs documentation, and Patch needs improvement\nflags are unchecked once you’ve addressed all review comments.
\nRemember that Django has an eight-month release cycle, so there’s plenty of\ntime for your patch to be reviewed.
\nFinally, a well-timed reminder can help. See contributing code FAQ for ideas here.
\n