Google's Summer of Code 2006

Django (and the Lawrence Journal-World) is a sponsoring organization for the ​2006 Google Summer of Code. (Read Google's page for more information on how the program works.)

Mentors

If you're interesting in mentoring -- supervising a student in work on Django-related activities -- ​sign up over at Google and then add your name below:

• James Bennett
• ​Simon Blanchard
• ​Matt Croydon
• Kenneth Gonsalves
• ​Adrian Holovaty
• ​Ian Holsman
• ​Jacob Kaplan-Moss
• ​Eugene Lazutkin
• ...

Students

Student applications open May 1st. Watch ​django-users for an announcement when the signups open.

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). We'll want to know a bit about you -- links to previous work are great, if any. You'll also need to provide us with a rough schedule of 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.

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

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.

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 SOC does not cover activities other than coding, so certain ideas ("Write a more detailed tutorial" or "Create demonstration screencasts" or "Add a pony") are not suitable for inclusion here.

• Build a public repository for reusable Django applications. This probably includes:
  • a standard way of packaging Django apps for distribution
  • infastructure for automatically downloading and installing packaged Django apps.

• Create Django packages and buildscripts for Linux (various), FreeBSD (There already is one www/py-django), OS X (Fink and Darwinports), etc.

• Create a generic, reusable search/indexer component.

• Enhance the admin's support of rich media:
  • create a file explorer for MEDIA_ROOT in the admin: browsing and making directories, uploading files
  • automatically make thumbnails from ImageFields (with programmable "PIL modes" (i.e. adding borders, overlaying png's))
  • validation of image type, sizes, etc
  • support for uploading large files through the admin with a pretty progress indicator

• Implement ModelInheritance.

• Implement SchemaEvolution.

• Implement a set of reusable AJAX components using Dojo and Django as a backend, including:
  • Non-admin widgets
  • Admin widgets to bring Django closer to, e.g., MicrosoftAccess (NB: if Django ever becames anything LIKE Access, I'm leaving. -- JKM) for creating database applications:
    • MultiSelectComboBox that works for thousands of rows and can display multi-column results
    • Easily create any levels of inlined editing widgets
    • Compose admin pages of AjaxPortlets that can be connected together

• Add spell checking to CharField and TextField with a well thought out interface (getting the interface right will be significantly harder than the backend code).

• Change the permissions system to be more flexible (ACL's, Zope-style role based authorization, etc.)

• Implement custom redirects and field templates for the admin system. (This isn't very ambitious as-is.)

• Refactor package settings so things like django.template are usable outside of django. ​details

• A better built-in webserver and an officially supported methodology to connect to lighttpd and similar servers. While the apache+modpython solution is highly performant there are numerous situations where that setup is unfeasible or overkill. It is great that Django scales up well, if would be great if it scaled downwards as far as setup and deployment goes.

• Streaming uploads and downloads. Uploading a large file can break django as the files are stored in the request. This is a security flaw as well, denial of service attacks could be as simple as uploading one large or more smaller files simultanously.

• Parametrized templates. Currently the only way to use the content of another template in a place that does not contain blocks is to include it. But that includes the whole template. It would be very nice if one could include blocks defined in other templates to be evaluated in a certain context. (this turned out to be harder to explain than I thought, basically what I'm saying is to introduce a new kind of block that works like a function, where you could call/import a block and pass it some parameters)

• ...