[[PageOutline]]
= Google's Summer of Code 2010 =

Django is once again applying to be a sponsoring organization for the [http://code.google.com/soc/ 2010 Google Summer of Code]. (Read Google's page for more information on how the program works.)

Django's SoC program is being run by Jannis Leidel (jannis /at/ leidel /dot/ info).

== Mentors ==

If you're interested in mentoring -- supervising a student in work on Django-related activities -- add your name and email here:

 * Jannis Leidel (jannis /at/ leidel /dot/ info)
 * Russell Keith-Magee (russell@keith-magee.com)
 * Ville Säävuori (ville@syneus dot fi)
 * Greg Wilson (gvwilson@third-bit.com)
 * Your Name (Your Email)

== Students ==

Student applications open March 29 and end on April 9.

If you'd like to get started on your proposal early, we'll be looking for a few things.  

 * You'll need to have a concrete task in mind (some ideas are below) along with a solid idea of what will constitute "success" (you tell us).  
 * If your proposal is a single large feature, you'll need to present a detailed design specification. This proposal should be posted to [http://groups.google.com/group/django-developers django-developers], where it can be refined until it is accepted by the developer community.
 * We'll want to know a bit about you -- links to previous work are great, if any.  If you're proposing something ambitious, you'll need to convince us that you're up to the task.
 * You'll also need to provide us with a schedule, including a detailed work breakdown and major milestones so your mentor can know if and when to nag you :)

Note that none of the ideas below are good enough to be submissions in their own right (so don't copy and paste)!  We'll want to know not just ''what'' you want to do but ''how'' you plan to pull it off.

Don't feel limited to the ideas below -- if you've got a cool project you want to work on, we'll probably be able to find you a mentor.  We plan on approving as many projects as we possibly can.

'''Note: we're looking for projects that add value to Django itself - ''not'' application/CMS projects that use Django.'''

You should also note that as far as proposals go, we don't make a distinction between a GSoC project and any other proposal for a new feature. When you contribute code, you will be expected to adhere to the same contribution guidelines as any other code contributor. This means you will be expected to provide extensive tests and documentation for any feature you add, you will be expected to participate in discussion on [http://groups.google.com/group/django-developers django-developers] when your topic of interest is raised. If you're not already familiar with [http://docs.djangoproject.com/en/1.1/internal/contribution/ Django's contribution guidelines], now would be a good time to read them. 

== Communication ==

The [http://groups.google.com/group/django-gsoc django-gsoc] Google Group has been setup to facilitate communication between students and mentors in the GSoC efforts. This list should only be used for GSoC administrative matters. Any discussions on the specifics of a given proposal should be directed to [http://groups.google.com/group/django-developers django-developers].

== Ideas ==

Here are some suggestions for projects students may want to propose (lazyweb: please add to this list!). This isn't by any means the be-all and end-all of ideas; please feel free to submit proposals for things not on this list. However, if you're going to propose something that isn't on this list, you might want to check on [http://groups.google.com/group/django-developers django-developers] to see if there is any interest before you start drafting a full proposal.

When developing your proposal, try to scope ideas/proposals to the 4-month timeline -- simply proposing to fix a ticket or two will probably result in your proposal being rejected in favor of a more ambitious one.  The GSoC '''does not cover activities other than coding''', so certain ideas ("Write a more detailed tutorial" or "Create demonstration screencasts" or "[wiki:AddAPony Add a pony]") are not suitable for inclusion here.

On the other side, though, be sure to be concrete in your proposal. We'll want to know what your goals are, and how you plan to accomplish them.

In no particular order:

=== Template compilation ===
 * '''Complexity''': High

A common criticism of Django's template language is that it is too slow. One reason for this is that the rendering process is handled at a very high level, interpreting a tree of tree nodes that have been generated by parsing the template source file. 

Other Python-based template languages gain significant speedups by compiling templates directly to Python bytecode. A Django template compiler would allow for similar templating speedups.

Issues to consider:
 * How does Django's template variable scoping rules map to a compilation scheme?
 * Django Template tags are able to modify the context as the template is rendered. How does this affect the compilation process?
 * How should we handle the upgrade path when compiled templates are added to trunk?
 
See also:
 * [http://groups.google.com/group/django-developers/browse_thread/thread/9da4fdb455a002b5 One proposal to implement template compilation]
 * The [source:django/trunk/django/template django.template code module]
 * Other template languages, like [http://jinja.pocoo.org/2/ Jinja2] and [http://www.cheetahtemplate.org/ Cheetah]

=== Enhanced auth.user ===
 * '''Complexity''': High

One of the most common class of questions on [http://groups.google.com/group/django-users django-users] surrounds issues of customizing Django's User model. For example:
 * How can I use an email address as a username?
 * I want to use Twitter/OAuth/Facebook to login - why can't I leave the username field empty?
 * How can I make the username field N characters longer/shorter?
 * How can I allow [insert random character] in usernames?
 * How can I have a single "name" field instead of "first_name"/"last_name"?

At present, there is no easy answer to these questions. Use of Django User model is not mandatory, but it is a dependency for a lot of Django applications. It is possible to do some of these customizations using some tricks or by manually modifying the contrib.auth source code, but these are not good solutions for novice users.

Ticket #3011 describes one approach that has been rejected - the idea of a 'pluggable' User model.

'''Note:''' This isn't a problem with an existing worked solution. A successful proposal on this project will require extensive discussion on [http://groups.google.com/group/django-developers django-developers].

Issues to consider:
 * How can we represent the generic idea of a User without reducing the user table to little more than an identifying primary key?
 * How can we differentiate the ideas of identity, permission and authentication?
 * How can we manage the dependencies that exist in contrib.admin (and other parts of Django core and Django.contrib) that rely on the internals of auth.User as currently implemented?
 * How can we roll out a new/modified User model without requiring almost every Django application on the planet to undergo a complex database modification?

See also:
 * #3011, and any discussion on [http://groups.google.com/group/django-developers django-developers] that references it.
 * Discussions on [http://groups.google.com/group/django-users django-users] when users have asked the "how do I" questions
 * The [source:django/trunk/django/template django.contrib.auth code module]

=== Housekeeping ===
 * '''Complexity:''' Minor

Django has gone through three recent cycles of rapid change, culminating in the release of versions 1.0, 1.1 and 1.2. These releases have all been feature heavy, which is good for ticking off checkboxes on feature lists, but it does mean that some internal housekeeping and code cleanup tasks have been avoided in order to deliver new features. These housekeeping issues would be well suited to a Summer of Code student wishing to gain a deep understanding of the internal workings of the Django framework.

Issues to consider:
 * Django's Model._meta class is officially internal API, but in practice, many parts of _meta are in such common use that they couldn't be changed without causing major problems to Django users. The contents of _meta should be surveyed, cleaned up where necessary, documented and tested as part of formal API.
 * While the public API for foreign keys and m2m relations in Django is quite elegant, the implementation is anything but. This implementation should be cleaned up.
 * There are several internal components (such as the datastructures library) that are heavily used, but have not been extensively profiled to ensure that they are efficient. Profile the Django test suite to find the areas of code that are performance bottlenecks, and optimize them.

See also:
 * Trac, bugs by component. Any component with lots of bugs is potentially a candidate for inclusion in this project.
 * [source:django/trunk/django/db/models/options.py The Model._meta class definition]
 * [source:django/trunk/django/db/models/fields/related.py The related fields implementation]

=== Improved error reporting ===
 * '''Complexity:''' Medium

The error messages raised by Django can sometimes be confusing or misleading. This is sometimes due to Django wrapping and re-raising errors when it shouldn't. Sometimes it's due to Django not displaying error information effectively. Sometimes it's simply a matter of not catching the right errors.

This should be fixed. Error messages are just as important to the development process as good documentation. This project would address the error reporting issues in Django to ensure that the errors reported by a Django project are as good as they can be.

Issues to consider:
 * Import errors discovered during application loading during can be masked under certain circumstances.
 * Errors in template tags and filters rarely produce helpful error messages.
 * Errors in ModelForm and ModelAdmin can raise errors that don't indicate the real problem

See also:
 * [wiki:BetterErrorMessages The Better Error Messages] proposal page
 * Ticket #3349

=== Improve annotation and aggregation ===
 * '''Complexity:''' Medium

The 2009 Summer of Code added the annotate() and aggregate() calls to Django's query arsenal. While these tools work well for simple arithmetic aggregates, they don't work well for date and string based queries. There are also use cases where you may want to annotate data onto a model that *isn't* an aggregate (for example, annotating the sum of two other aggregates). 

This project would continue where the 2009 GSoC aggregation project left off. This would be an excellent project for anyone wishing to gain an intimate understanding of Django's Query infrastructure.

Issues to consider:
 * String concatenation and manipulation
 * Grouping of results by date
 * Allowing non-null defaults in aggregation
 * Edge cases 

See also:
 * [http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=ORM+aggregation&order=priority Trac's list of ORM aggregation tickets]
  * The [source:django/trunk/django/db/query.py Django's QuerySet implementation]

=== Customizable serialization ===
 * '''Complexity:''' Minor

Customizable Serialization. Define a class-based structure that allows users to define their own serialization format (including different output structure, including non-model fields, etc). Define Django's own serializers in that format.

Issues to consider:
 *

See also:
 *
 
=== App loading ===
 * '''Complexity:''' Minor

Refactoring of the app loading mechanism (ref. #3591)

Issues to consider:
 *

See also:
 *

=== IPv6 support ===
 * '''Complexity:''' Minor

Implement proper IPv6 support in django (ref. #11442, #7735, +++)

Issues to consider:
 *

See also:
 *

=== Testing updates ===
 * '''Complexity:''' Minor

Update Django's system tests -- migrate Doctests to UnitTests, and merge the modeltests and regressiontests directories.

Issues to consider:
 *

See also:
 *