Version 272 (modified by anonymous, 13 years ago) ( diff )

--

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

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. 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 inadvertantly 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. ​inteligator review

Suggestions

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
  • #14643 & #14497 better widgets for readonly_fields

Results

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

GeoDjango

​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.
Note: See TracWiki for help on using the wiki.
Back to Top