Google's Summer of Code 2017

The application process for 2017 Google Summer of Code is coming soon, and Django applied as a mentor organization. Read ​Google's page for more information on how the program works.

Django's GSoC program is being coordinated by Tim Graham.

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 (IRC: timograham, timograham@…) - Anything, most likely.

Students

Student application period opens March 20 ends on April 3.

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

How can I improve my chances of being accepted?

The best thing you can do to improve your chances to be accepted as a Django GSoC student is to start contributing now. Read up on ​Django’s contribution documentation and make yourself known to the core team by your contributions (ideally, related to the area of your proposal). That way, when it comes time to evaluate student applications, you’ll be a known individual and more likely to be able to get the attention you need to develop a proposal.

Communication

All GSOC-related communication is handled 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.

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") 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: Hard

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 however the frontend tech world is currently in a state of reinvention so it might be hard to develop a suitable API that's suitable now but not in the future.

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)
• Part of this task could be auditing ​Django's coverage report and adding missing tests and removing dead code.

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

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.

Template engine optimisation

• Complexity: Medium

Django's Template Language is not known for its speed, but to date little work has been published on properly profiling its internals. Many feel there is a lot of redundant work being done in the name of surety. The aim of this project would be to profile the engine and find ways to optimise the render process.

This would best be achieved by constructing a suite of rendering benchmark tests so any chances can be evaluated meaningfully for their trade offs.

Formset improvements

• Complexity: Low

One of the big problems in web programming is making a request object available everywhere that it might be needed. Some frameworks tackle this problem by using a threadlocal. A threadlocal is essentially a global variable that allows you to access stateful information, such as the currently active request.

Django takes a more structured approach, and encourages you to use function arguments and class attributes to pass around stateful information. This requires more discipline on the developer, but ultimately leads to more robust, less error-prone code that is easier to test.

The counterargument to Django's approach is that passing the request around everywhere that it might be needed is difficult. Formsets are one example given in support of this - Django's formsets are a classic example where you might want to pass a request down to an internal form - but this is surprisingly difficult to do with Django's FormSet infrastructure.

The problem isn't just about requests, either - there's a general problem in Django's FormSet and ModelFormSet objects that makes it difficult to pass in arguments to the Forms that are on them, or otherwise control the save process. This could be a request, the user that is making a particular change, or some other "ownership" related information.

While it is *possible* to work around this problem, it *should* be a well documented, easy to use capability.

Improved autoreloader (#27685)

• Complexity: Medium

Django's development server includes an auto-reloader. Its design is quite old. It keeps a list of imported Python files (as well as .mo files, there's a hardcoded special case), checks every second the mtime of these files, and triggers a reload if a file was updated. This cannot be good for battery life.

A more efficient implementation based on inotify is available on Linux. An implementation based on kqueue was developed at some point but quickly removed because of kqueue limitations (#21621).

Several open-source projects provide modern and robust building blocks for building the autoreload feature. The most mature in general is probably watchman. The most mature Python library is probably watchdog. However their APIs are quite low level and there's no trivial way to integrate them with Django's development server.

The first goal of this project is to figure out and implement this integration. This means rebuilding the development server's autoreloading feature, perhaps with a slightly different behavior and hopefully with better performance, while preserving the main APIs (runserver, runserver --no-reload).

It would make sense to switch from watching all imported Python files to watching the current directory. Modifying non-Python files whose content is somehow cached in the Python process happens and is regularly reported as a bug, while modifying files in $VIRTUAL_ENV/lib/pythonX.Y/site-packages is an uncommon case.

It will be a good opportunity to fix various bugs of the autoreloader such as the inability to detect the addition of a file, typically an admin.py.

The second goal is to improve configurability of the autoreloader, perhaps by exposing the underlying library's configuration knobs. This will allow people to customize the behavior according to their needs, for example if they want to go back to the previous behavior and watch $VIRTUAL_ENV.