Version 266 (modified by Russell Keith-Magee, 7 years ago) (diff)

Removed links to resolved tickets

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

There are no sprints planned at this time.

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

See the suggestions at the bottom of this page.

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. Some issues are intrinsically controversial. For the sake of your own sanity, avoid these tickets during the sprint.
  • Fix old bugs. There are any number of small, annoying bugs that have hung around for a long time. Some of them have patches, but the patches need to be updated. Start with the bug low numbers, and work up until you find something that interests you.
  • 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.

You might want to search for tickets that have the patch needs improvement flag set and try to improve the patch (there will be something in the comments suggesting what improvement is needed). Or look for tickets with needs tests or needs documentation and try to fill in those gaps.

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 confirm them, or handle them according to the triage guidelines.
  • Confirm existing bugs or work out how to repeat them.
  • Look for tickets in the unreviewed state and see if you can repeat the problem.
  • 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.
  • Look for tickets needing documentation or needing improved documentation and try to complete them.


So you've joined the sprint and don't know where to start? Try one of these tasks!

  • Whilst working on a task, assign it to yourself so other people know that it's yours.
  • If you complete a task, edit this page and remove the task from this list and add it to the proper results section below
  • If you make progress on a task and then leave it, edit this page leaving a note of what you've done.
  • Any of the sprint specific goals and tickets: read the page dedicated to this specific sprint.
  • FormPreview and related tickets
  • Sort out what's happening with limit_choices_to (#1891, #2445)
  • #1028 Add more elements to the high-level RSS Framework.
  • #2539 add unit tests and docs for Custom tags and filters can be restricted by namespace
  • #4030 Review the suggested patch for enabling auto-translation of language names
  • #7783 confirm which versions of postgres the patch works on.
  • GeoDjango tasks


If you believe you've successfully dealt with a ticket, post it here so a core dev can have a look at it. Please order by ticket ID. Note: Don't close the tickets until they've been checked in.

Results of pycon08 sprint

  • #2723 (dec 07 sprint work) Added unit tests and improved patch, marked as ready for checkin during pycon08 sprint
  • #3542 (dec 07 sprint work) already marked as ready for checkin, patch updated to trunk

Results of 1stDecember07 sprint

  • #2723 added patch (newforms-admin)
  • #2856 added patch
  • #4680 updated with tests
  • #3542 added patch
  • #4499 tested this, and could not reproduce
  • #5622 added patch
  • #6055 GenericRelation and db_column lookups

Results of september07 sprint

  • #1919 filter truncatewords wipes newlines from string, so not chainable with markup filters
  • #2504 ConditionalGetMiddleware causes Content-Length to be 0 on HttpResponse with fileobject
  • #3055 Invalid ticket as model in GenericRelation requires content_type/object_id fields.
  • #3485 Initial SQL fails when data contains a % in it when settings.DEBUG = True
  • #3997 small note in the docs about fields being required by default in an instance
  • #4094 patch to fix problem with months in databrowse calendar views
  • #5116 let newforms.Select display disabled entries
  • #5298 The extra_context keyword argument should be available in the auth app views
  • #5418 Add assertNoBrokenLinks() to test system
  • #5419 Fuzz testing assertions created along with some documentation
  • #5494 Fixed a bug in javascript message catalog search.

Other branches


Open GeoDjango tickets

Task list (in order of importance):

  • #5472 Add OpenLayers support in django.contrib.gis.maps
  • Fill out the documentation stubs and fix inconsistencies between the documentation and the code.
Back to Top