Google's Summer of Code 2007

Django is a sponsoring organization for the ​2007 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 -- list your name below, wait for March 14, and ​sign up over at Google:

• ​Eugene Lazutkin
• Joseph Kocherhans

Students

Student applications opened March 14; ​sign up over at Google and be sure to list Django as the project you want to work with. You should do it before March 24!

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.

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

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.

In no particular order:

• Add optional object-level caching for objects in the cache backend
  • Queries would still go to the database, but the DB could return only IDs... actual object retrieval could go through the cache system
  • This would result in more DB queries on cache-miss, but fewer overall
  • This is useful for pages where dynamic output is required, so whole-page caching is not feasible
  • Coherency could be maintained by invalidating/replacing the cached copy when an object is saved
  • It should be possible to force the retrieval to pull the record from the database if the programmer knows it is necessary (DB-level coherency is required)
• Finalize TextIndexingAbstractionLayer and get it merged into trunk
• Finalize FullHistory and get it merged into trunk
• Finalize SchemaEvolution and get it merged into trunk
• Finalize RowLevelPermissions and get it merged into trunk
• Placeholder - add your ideas here.