Google's Summer of Code 2015

The application process for ​2015 Google Summer of Code is coming soon, and Django plans to apply to be a mentor organization (Read ​Google's page for more information on how the program works.). If past results are an indication of the future, it's quite likely we'll be accepted as a mentor organization. This page is a placeholder for ideas in the meantime, since we seem to have a lot of eager people wanting to get started!

Django's GSoC program is being run by TBA.

Mentors

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

• Tim Graham (timograham@…) - Replace Form Media

• Marc Tamlyn (marc.tamlyn@…) - Test framework cleanup
• Russell Keith-Magee (russell@…) - Replacing middleware, SQLAlchemy / NoSQL integration

Students

Student application period opens March 16 ends on March 27.

If you'd like to get started on your proposal early, we'll be looking for a few things. Note that we've widened our project scope this year!

• 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, library or site, you'll need to present a detailed design specification. This proposal should be posted to ​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 :)

Here's an example of an accepted proposal from a previous year:

• ​https://gist.github.com/chrismedrela/82cbda8d2a78a280a129

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.

We're accepting any GSOC proposal that fits one of the following three categories:

• Work on Django itself - such as the ORM, forms, etc. This is what we've traditionally accepted GSoC entries in.
• Work on tools to support Django - the dashboard (​https://dashboard.djangoproject.com/) is a good example of an existing tool that would have fit into this category.
• Work on libraries that supplement or add new features to Django to ease development - South and Django Debug Toolbar are good examples of existing projects that would have fit here.

We're not looking for people to work on existing third-party libraries - we aren't able to guarantee commit access to them. We may allow an exception if a maintainer of the library in question agrees to help mentor beforehand.

The broadening in scope is to allow people to work on new ideas to help Django development and developers without tying you down to having to implement it in the core codebase (and thus ruling out some projects that might otherwise be useful).

We're still going to be strict with what we accept - you'll need to provide a strong use case for your idea and show that it would be useful to a majority of developers or significantly improve the development of Django itself.

We're not looking for small groups of incremental updates - like "improve Django's Trac" - nor are we looking for impossible tasks, like "replace Trac with this brand new issue tracker I'm writing". What you propose should be a single project, achievable within the time period of GSoC, and something the core developers can help mentor you on.

We're also not looking for sites or projects that are merely written in Django - this GSoC is not for you to propose your new forum hosting site or amazing Django-based blogging engine.

Note that 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 ​django-developers when your topic of interest is raised. If you're not already familiar with ​Django's contribution guidelines, now would be a good time to read them - even if you're not applying to work on Django core directly, we'll still want the same level of contribution.

Communication

This year we're doing all GSOC-related communication via the ​django-developers mailing list. Any proposals for GSOC should be submitted there, as well as discussion on the proposed projects and any updates that students post.

Please be careful to keep content to the list clear and purposeful; if you have an idea, update, or criticism, please make sure you describe it in detail; it can be tedious asking people to clarify any vague statements, or having vital information drip-fed.

Ideas

Here are some suggestions for projects students may want to propose (please feel free 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. Remember, we'd much prefer that you posted a draft proposal and your rough timeline / success conditions to the ​django-developers list, even if it's already on the list below; it will help you get feedback on choosing the right part of a problem, as well as helping 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 "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:

Replace Form Media Class

• "Complexity:" Moderate

Quoting Loic on the ticket: "My biggest issue with it is that it's a very naive approach to a complicated problem. It doesn't really fit with today's development practices where a project can easily grow to hundreds of static assets, where javascript offers concepts like AMD, where CSS gained preprocessors like LESS or SASS and where files are concatenated for performance.

Having each input widget pull it's own assets can also be a performance footgun, and IMO it's hardy something we should recommend."

You will need to come up with a design here. There are a variety of third-party libraries from which you might glean best practices.

Best practices updates

• Complexity: Moderate

Over the years, as Django has evolved, the idea of what constitutes "best practice" has also evolved. However, some parts of Django haven't kept up with those best practices. For example, contrib apps do not use class based views.

In short, Django has been bad at eating it's own dogfood. The contents of contrib should be audited and updated to make sure it meets current best practices.

Issues to consider:

• What components need to be updated, and why?
• How to do this update while maintaining backwards compatibility?

See also:

• #8579

Test framework cleanup

• Complexity: Low

Django has an extensive test framework for Python code, a suite of tools to make server-side testing easier, and a project policy that no new code is added without tests. This has been a significant contributor to the stability of Django as a project.

However, this now means that Django has a very large and powerful test suite without much separation or control from a user's perspective, so the goal of this project would be to add new options and suite types to allow running of specific types of tests, be they only a certain class (e.g. unit-tests only, selenium tests only) or excluding tests (such as the ones in contrib or third-party apps) from the main test run easily.

Django's test suite is also very large with over 1000 models. In some areas, the tests are poorly structured and it is not clear where similar related tests should be placed. It is likely there may be some duplication of features tested, and there are certainly edge cases which are not tested. For example, standardising all the unit tests necessary for a particular model field type would be beneficial.

Issues to consider:

• How would users declare which tests they want to run?
• Which tests should be enabled by default, and how hard should this be to change?
• How will it be app maintainers run their tests?
• Should there be additional hooks to, for example, allow tests to be run against different database backends in sequence?
• Are there tools similar to the new --debug-sql option which would help developers working on Django?

See also:

• #13873 (more of a symptom of this problem)
• More tickets need to be added here

Security Enhancements

• Complexity: Medium

Django has developed many security features over time. The existing set of security features is pretty good, but there's lots of room for improvement. Much of the work in this project will be related to cleaning up existing code to make it more obviously secure, eliminate edge cases, and and improve fallback handling.

Some potential areas of work include:

• Enhancing CSRF protection (#16859)
• Centralizing randomized token issuance and validation
• Building an interactive admin dashboard to display and check installation security parameters
• Targeted Code audit for a specific list of security errors

While an interest in security will make these tasks more interesting, most of them don't require you to be a security expert already. Your mentor will make sure your plan is correct before you code, and carefully review your work before it is committed to trunk. Most of these tasks will be significantly easier if you already have some familiarity with Django's codebase. A successful application will have a plan which selects related areas of work, provides details, and has a good estimation of complexity for the proposed tasks. Remember that (especially for security work) a good patch often has more lines of tests than code changes. An ideal applicant will be able to demonstrate the skill with Python and attention to detail necessary to make fundamental changes to Django without breaking existing code.

Ideas that will probably not be accepted:

• Adding database or cookie encryption support (unless you can provide a secondary mentor who is a crypto expert)
• Proposals that strongly couple sessions with CSRF or Auth
• Proposals to include external libraries in Django

If you are interested in working on this project, please talk to us sooner rather than later! PaulM is usually available on IRC, and wants to help you write a really good application.

Reducing coupling in Django components

• Complexity: Hard

Django is currently delivered as a single monolithic download. This is largely for historical reasons; when Django started as a project, Python's packaging infrastructure wasn't especially mature. This situation has has improved over the years, and now Python has a rich set of packaging tools. In an ideal world, it would be possible to download "Just the Django template engine", or "Just the Django ORM", or "Just the Django forms layer"; the combined Django download would really be a meta-package install of all the required parts.

There are two technical problems that need to be solved in order to make this happen.

• Implement the packaging definitions to allow for multiple packages.
• Clean up dependencies between components. Despite the best of intentions, there are some interesting dependencies between modules, some of which may need to be clarified or separated.

The aim of this project would be to clean up one or more of Django's internal "parts" so that it could be delivered as a standalone package. This may not be something that can be immediately delivered - for example, it may be necessary to move or rename components to enable separate packaging. In this case, the project deliverable would be to document the strategy, and provide whatever initial moves in that direction are possible.

A simpler version of this project would be to enable separate packaging and distribution of Django's contrib apps.

Improving the less popular database backends

• Complexity: Medium

Django supports several database backends, but not equally. The less popular backends -- Oracle in core, as well as open-source backends outside core, could probably use some love. As an example, Oracle has some problems:

• The handling of case in database object names is problematic (e.g. #20487)
• Add more issues?

While these alone would not fill an agenda for a full GSoC project, an interested student could collect enough related issues -- perhaps in more than one backend -- to keep busy for the whole term.

Keep in mind that for working on 3rd-party backends, a committer for the relevant backend will probably need to be involved in mentoring; however, given such involvement, Django will accept such GSoC projects.

See also:

• Trac's list of Oracle issues
• Similar queries for 3rd-party backends should be added here

Improving URL dispatch

• "Complexity:" Hard

Django's URL routing infrastructure hasn't had any significant changes since it was originally introduced. As a result, there are some areas that are ripe for improvement.

Django's middleware infrastructure is not particularly good. In particular the handling of exceptions is not necessarily predictable.

It also has no way of applying itself to anything other than the entire site. With the advent of class based views, decorators are not particularly clean, and are also easily omitted. For example consider an entire reporting section which requires certain permissions - applying the permission requirement at the URLconf level reduces the chance of missing single views and leaving security vulnerabilities.

There is also a need to look at URLconfs and the URL resolution process. The current URL dispatch mechanism is hard coded, and is somewhat limited. However, if this mechanism could be customised, it would be possible to introduce new features, or even an entirely different URL dispatch mechanism, supporting features such as:

• Domain based dispatch
• Wrapping multiple URLs, or entire URLconfs in a decorator/middleware
• Alternate schemes for URL definition (e.g., a non-regex based pattern matching system)
• Alternate schemes for URL registration (e.g., a routing-based URL system)

SQLAlchemy / NoSQL integration

• "Complexity:" Medium

With the success of the 2014 GSoC project to formalise Meta, we're now in a position to use that interface to do interesting things.

A common request over the entire life of Django has been to use Django's forms (and in particular, Django's Admin) with data stores that aren't Django's ORM. SQLAlchemy is a popular choice for those using SQL databases; a number of NoSQL data stores have also been popular at various times.

The aim of this project would be to take a set of models defined in a non-Django data store, and define the mechanisms necessary to expose those models in Django's contrib.admin interface. Daniel (last year's GSOC student) proved this was possible by providing a proof-of-concept interface to Gmail inside contrib.admin.

There will be two parts to this project:

1. Developing a Django-Meta compliant interface for your non-Django data store of choice.
2. Fixes and improvements to Django itself as necessary to support (1)

The code produced under part (1) would be a standalone repository and project, *not* a candidate for inclusion into Django itself. Django won't be gaining official SQLAlchemy support - but we will be able to point at a viable proof of concept.

This project could be taken up by several GSoC students, with each student developing a backend for a different data store. If more than one student is accepted for this project, they'd be expected to coordinate efforts on any bug fixing and/or improvements required in Django itself.