Google's Summer of Code 2020

Django is a mentor organization for the 2020 Google Summer of Code. Read ​​Google's page for more information on how the program works.

Django's GSoC program is being coordinated by the current Django Fellows, Carlton Gibson and Mariusz Felisiak.

Mentors

If you're interested in mentoring -- supervising a student in work on Django-related activities -- let us know via the Mentoring topic on ​https://forum.djangoproject.com/.

Students

Student application period opens March 16, and ends March 31, 2020.

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.

We're looking for candidates who can demonstrate that they can engage in work of a project scope on an independent basis. We're there to help but we can't watch you every step of the way, so we need to see that motivation from you. Being active before the submissions process is the best way to demonstrate this.

Communication

All GSOC-related communication is handled via the ​​Django Forum, in the Mentoring channel. 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 forum 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:

Make the parallel test runner work on Windows

Currently we can't run the Django test suite with parallel processes on Windows. This is because the subprocess module uses a spawn method on Windows, which requires the entire process to be bootstrapped from scratch, vs fork on posix systems, which has the child processes sharing various state with the parent to begin.

Rewrite the parallel test runner to use the spawn method, and so be able to be used on Windows.

Migrations

Adapt schema editors to operate from model states instead of fake rendered models.

This is Ticket #29898.

Secrets Manager

Many environments Django is deployed in use a separate secrets manager to store and provide secrets per environment - either as environment variables, files, or via a direct HTTP API. The project would be to design and add an abstraction interface over secrets managers that allows users to easily map to an external secret in a settings file. There's also room for giving Django a better, built-in per-environments settings option too, pulling from popular third-party patterns.

Django Service Hooks

Django has a lot tied to the HTTP lifecycle, and if you run it outside of this, you miss out on some key things - like database connections being closed properly, or logging, or some middleware. The project would be to design and implement a separate way of calling Django from a service framework - even if that framework was itself HTTP based (basically, don't rely on Django having to run through WSGI/ASGI). Initial idea is to provide a context manager that replaces the wrapping of a request, but the project would have to include requirements-gathering and interviewing people who use Django to power microservices to work out what they want.

Evented Datastores

Evented, or event-sourcing, database schemas are growing in popularity - essentially, a way to implement an append-only pattern on top of a relational database, where every single event that has happened is stored, but you can still efficiently retrieve the current state of an item. Given the way the pattern works, this would be possible to implement on top of Django models - likely as a whole new Model subclass - and implement with a matching QuerySet/Model API. It would require someone very skilled in database design, and it's also arguable if it should be in Django itself, or comprise of developing a third-party app alongside adding hooks/fixes to the Django ORM where needed to make it work well.

GraphQL

Basically, work on an "official" graphql-to-ORM mapper for Django, probably re-using a considerable amount of third-party work. This one could really vary in its application, based on how much other "API-ish" work the project includes (given that Django REST Framework is still separate, we should follow that rough pattern).

Django Benchmarking

​https://github.com/django/djangobench

Django has had a benchmarking suite for a while, but we've generally got more slack at tracking the effects each commit and release has. We should institute a set of top-level benchmarks aimed at various areas (the current set in djangobench are weak in, say, the HTTP-serving-speed area) and then run them against pull requests and each release, so we can make sure Django doesn't get slower while nobody is looking.