= What to work on during the Django sprint =

More than 100 people around the world have signed up for Friday's Django sprint. What should ''you'' work on, given that so many other people are contributing at the same time? This document attempts to help you answer that question.

== How to prepare for the sprint ==

 * Join the [irc://irc.freenode.net/django-sprint #django-sprint IRC Channel].
 * Read our [http://www.djangoproject.com/documentation/contributing/ "Contributing to Django" document].
 * [http://www.djangoproject.com/documentation/install/#installing-the-development-version Install the "trunk" version of Django] (aka the Django development version).
 * [http://www.djangoproject.com/accounts/register/ - Create an account in our ticket system]. This will allow you to claim tickets you're working on.

== 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 [http://code.djangoproject.com/wiki/SprintIdeas#Suggestions 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, such as the question of how (or whether) to implement auto-escaping in templates. 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 [http://code.djangoproject.com/query 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 [http://groups.google.com/group/django-developers/about 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.

 * [http://code.djangoproject.com/query 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, [http://www.djangoproject.com/documentation/contributing/#claiming-tickets 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 [http://www.djangoproject.com/documentation/contributing/#unit-tests 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.
 * [http://www.djangoproject.com/documentation/contributing/#patch-style 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 [http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&order=priority&stage=Unreviewed unreviewed tickets] -- try to confirm them, or handle them according to the [http://www.djangoproject.com/documentation/contributing/#ticket-triage 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.

== Areas requiring caution ==

There are a few areas in Django that are undergoing some fairly major change. Have care if you are wanting to work in the following areas.

=== Admin interface ===

Joseph Kocherhans is leading the charge to finish the NewformsAdminBranch, which will replace the existing admin code as soon as possible.

Consequently, any tickets against the existing admin code that are not real showstoppers and having small impact are unlikely to be applied. We would rather develop the same patch against newforms-admin and fix the problem permanently over there.

By all means, pick some admin tickets to work on. However, read the ticket and try to repeat the problem on newforms-admin. Then write a patch against that branch, rather than trunk.

=== Database query construction ===

There are a lot of tickets concerning bad SQL constructs from the ORM. Malcolm Tredinnick is working in the QuerysetRefactorBranch to fix a lot of these. Right now, that branch is not in a usable state for any serious code; large pieces remain to be ported.

Any tickets having to do with SQL constructs will generally be fixed in that branch and merged into trunk. Malcolm has been putting the ''qs-rf'' keyword on tickets that are of this nature. The ''qs-rf-fixed'' keyword is being used for tickets that are fixed on that branch (eventually, all ''qs-rf'' tickets will move to ''qs-rf-fixed'').

If you come across a ticket that looks like a !QuerySet problem and has to do with SQL construction, add that keyword.

== 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
 * If you make progress on a task and then leave it, edit this page leaving a note of what you've done.

  * discuss then do #2750 - `ManyToManyField ignores 'default' option`
  * discuss then review #2983 - `ImageField not deleting previously attached file when updated`
  * discuss/review #3496 - `WSGI handler dies on a form containing only empty checkboxes`
  * discuss then do #3652 - `ChoiceField formfield for IntegerField and CharField`
  * review #4539 - translation.ugettext loses variable content from blocktrans
  * !FormPreview
    * Write documentation - #5432
    * review related tickets: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=django.contrib.formtools&order=priority
  * review #3724 - `Add Links for ImageField and FileField in admin_list.py`
  * discuss limit_choices_to
    * http://code.djangoproject.com/ticket/1891
    * http://code.djangoproject.com/ticket/2445
    * http://code.djangoproject.com/ticket/4046
    * limit_choices_to admin related: (keeping in mind newforms-admin)
      * #29 - `Fix usability issue with limit_choices_to and "Add another" in admin`
      * http://code.djangoproject.com/ticket/3096
 * review #4076 - `Patch to Output Timezone in Date Fields for Atom Feeds`
 * do #4223 - `Document how to create tests for Django framework itself`
 * review #4091 - `Not able to get choices widget to auto selected="selected" on model_for_instance`
 * #3961 refactorise Luhn function in za-localflavor and add tests
 * #4036 implement Malcolm's ideas in es-localflavor
 * #4092 implement a "missing option" in localflavor widgets
 * #1028 Add more elements to the high-level RSS Framework. Note that #3502 has time-to-live.
 * #3594 Javascript setlang bug (with proposed patch) needs tests, please implement and double-check the patch
 * #4030 Review the suggested patch for enabling auto-translation of language names
 * #4094 databrowse calendars do not translate the month back to english resulting in an error
 * #4692 write up some documentation about the required database permissions
 * #5264 Work out which version of Flup Django likes best
 * do #4245 - `add documentation solving "permission denied" with start-project on OSX`
 * add unit tests and docs to #2539 - `Custom tags and filters can be restricted by namespace`
 * #5389 - daily_cleanup.py looks to be broken after [6087]
 * #5418 - Add assertNoBrokenLinks() to test system
 * #5415 - Every SQL query should send a signal if possible

== Results ==

If you believe you've successfully dealt with a ticket, post it here so a code dev can have a look at it.

 * #208 refactoring of a patch improving {% cycle %}
 * #899 old small patch which needed tests, added regression tests
 * #2675 patched django.utils.timesince and template docs, and added tests
 * #2970 simpler patch for case insensitive http headers handling 
 * #3091 improved patch quality to expand flexibility of views in django.contrib.comments 
 * #3360 One Django badge on community page is cut off.
 * #3922 clarification in the doc for form_for_model's callback
 * #4061 Document how to restrict access to databrowse, based on info in this ticket
 * #4071 cache_page decorator sets wrong Cache-Control header
 * #4115 Thumbnail contrib.  Updated with effbot's comments.  Has tests and docs.  Should be good to go.
 * #4879 post_create signal
 * #4913 need permissions to add a links to wiki Resources and Tutorials from the main page
 * #4944 mentioned that unique might cause save() to throw IntegrityError in model-api.txt
 * #4960 to be closed 
 * #5286 - Non-HTML output in python manage.py adminindex <appname>
 * #4982 {% blocktrans %} does not escape % in text
 * #5047 max-age set by cache_page is overwritten by cache_middleware
 * #5364 mentioned form_for_model().save(commit=false) in the docs
 * #5394 - REDIRECT_FIELD_NAME should be configurable - update patch to match Adrian's suggestions.
 * #5454 - Using a user-built DB backend
 * #5457 move permission checking to the auth backends.
 * #3997 small note in the docs about fields being required by default in an instance
 * #3036 Added patch to fix a few doctests
 * #3988 Added Canadian localflavor tests
 * #5203: Performance improvement for sqlite3 database flush
 * #5145 invalidate because ticket doesn't meet newforms specification
 * #4604 Message Passing For Anonymous Users

== Other branches ==

=== GeoDjango ===

Task list (in order of importance):

 * A patch to work with the QuerySet refactor changes -- but this depends on the status of that branch,
 * Distance queries: we want an API with something like `distance_lte`, etc. and be able to take a Distance object (django.contrib.gis.measure) as a parameter. This is difficult because the differences between spatial reference systems
 * Add OpenLayers support in django.contrib.gis.maps
 * Fill out the documentation stubs and fix inconsistencies between the documentation and the code