= 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.

== 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.)

== The long 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.

== "Big" items ==

If you are 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. 

Remember that not everybody is going to be online all the time and those that are may well be busy on other things. So 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 everybody 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 are interested in or wish 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.

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.

== 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, drop in the keyword.