What to work on during a Django sprint

Given that so many other people are contributing to Django, at the same time, during sprints. What should you work on? This document attempts to help you answer that question.

Next upcoming sprint

See Sprints

How to prepare for a sprint

What to work on? The short answer

Work on whatever you like.

Our development process during the sprint will fundamentally be no different from standard Django development -- that is, contributors scratch their own itches, solve the problems they want to solve, and generally do what they want to do. The difference in the sprint, of course, is that a lot of people are going to be in more-or-less real-time contact, which makes it easier for more contributions to happen faster. (Some sprinters will be in the same physical location and the IRC channel will be available for more rapid feedback.)

What to work on? The concrete answer

So you've joined the sprint and don't know where to start? Try one of the LittleEasyImprovements! While working on a task, assign it to yourself so other people know that it's yours.

What to work on? The longer answer

If you're in doubt about what to work on, consider these pieces of advice:

  • Fix existing bugs, rather than adding enhancements. Bugs are cases where we know something is not working correctly or as documented. Enhancements require a bit more of a judgment call from the maintainers about whether to include the feature, and one big goal of the sprint is to try and reduce the number of open tickets by getting patches committed and tickets closed.
  • Choose noncontroversial tickets. If a ticket is very old, but hasn't been closed, there's usually a reason -- some issues are intrinsically controversial. For the sake of your own sanity, avoid these tickets during the sprint.
  • Review existing patches. There are lots of tickets in Django's tracker that have a patch, but either ​need tests or ​need some improvement to address technical issues. These are quite long lists of tickets; if you want narrow these lists, try starting with tickets targeting the current development version. Another place to start is the list of tickets at the end of this page consists of tickets that have been worked on in past sprints, but haven't been committed; this means that there is probably a starting patch.
  • Zero in a particular component you're familiar/comfortable with. It's overwhelming to browse the ​full list of open tickets, so do yourself a favor and narrow it down by component. (Do this by selecting "Add filter" on the right side of the page.) Example components are "Documentation" or "RSS framework." The nice thing about this approach is that, once you've fixed one or two tickets, you'll get on a roll and will have learned enough about that particular component that subsequent tickets for the same component will be easier to fix.

How to handle "big" tickets

If you're going to work on a really big item, either individually or as a group, remember to respect normal practices. Post a summary of any big discussions you have to the ​django-developers mailing list, and leave a comment on the ticket with a link to the discussion.

Remember that not everybody is going to be online all the time, and those that are may well be busy on other things. Large changes or things requiring community input will have to go through the usual, archived channels. That being said, an online or in-person discussion can get a lot further quickly, and then you can post a more comprehensive plan and summary than normal. So there are advantages to doing some design work in a sprint setting.

Working on smaller items

The biggest contribution anybody can make during a sprint is to help confirm bug reports, write patches, review proposed solutions and help get the tickets closed.

Pick an area you're interested in or want to learn more about. The general procedure is choose a ticket, replicate the problem, write a test, write a fix, go back to start.

  • ​Search for tickets in that component in Trac (one of the search filters is on the component type).
  • Read through the ticket titles until you find something interesting and try to replicate the bug.
  • Once you've found a ticket that interests you, ​claim it, so that somebody else doesn't accidentally duplicate the work.
  • If possible, write a test to duplicate the problem. Django's tests are in the tests/ directory, and we have ​some documentation about them. Copy existing tests as a start. If possible, look for an appropriate file to add your new test to, rather than starting a new file. But if you are working on a totally untested area, start a new file.
  • ​Write a patch, whether that is code or documentation to fix the problem.
  • Attach the patch to the ticket.

If your patch is more than a few lines long, don't forget to include your name in the AUTHORS file as part of the patch. We order that file alphabetically by surname.

Don't worry if it takes you longer than other people to write fixes initially. Some areas are genuinely harder than others. Some problems are disguised versions of something much bigger, so it might take a couple of attempts to get something that satisfies the maintainers. Not to worry; any serious patch is better than no patch because it gives us something to start from and incrementally improve.

Things for people not confident squishing bugs

If you're not confident fixing bugs in the core code, there are still other ways to contribute:

  • Triage the ​unreviewed tickets -- try to reproduce the issues they describe, or handle them according to the ​triage guidelines.
  • If the explanation of the bug isn't clear, work out what the reporter is talking about and add that in a comment on the original ticket.
  • Find bugs that have been confirmed and explained, but haven't got a programatic test case. Every bug that is fixed in Django should be accompanied by a regression test to make sure the problem doesn't arise again. Once a test case exists, it's much easier for someone who understands the internals to fix the problem.
  • Look for tickets ​needing documentation or needing improved documentation and try to complete them.
  • Verify that old bugs still exist. Sometimes bugs get inadvertently fixed; either they're re-reported but not identified as duplicates, or a fix for one bug corrects another bug. These old tickets will continue to linger in the bug tracker unless someone confirms that they are no longer a problem.
Last modified 10 years ago Last modified on Jun 27, 2015, 1:01:24 PM
Note: See TracWiki for help on using the wiki.
Back to Top