[[PageOutline]] = Google's Summer of Code 2023 = Django is a mentor organization for the 2023 Google Summer of Code. Read ​[https://summerofcode.withgoogle.com 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 runs until April 4, 2023. 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 [https://forum.djangoproject.com/c/internals/mentorship/10 the Django Forum], 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 issue tracker 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. Unless explicitly mentioned below, 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 [http://groups.google.com/group/django-developers django-developers] and the [https://forum.djangoproject.com Django Forum] when your topic of interest is raised. If you're not already familiar with [http://docs.djangoproject.com/en/dev/internals/contributing/ 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 [https://docs.djangoproject.com/en/dev/internals/contributing/ Django’s contribution documentation] and make yourself known to the other contributors 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 [https://forum.djangoproject.com/c/internals/mentorship/10 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 the [https://forum.djangoproject.com/c/internals/mentorship/10 Django Forum, in the Mentoring channel] or [http://groups.google.com/group/django-developers 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 size of your project (175hrs or 350hrs) -- you need to be ambitious, but not too ambitious. 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. The project ideas below list key skill, but all assume a knowledge of Python, and familiarity with Django itself. In no particular order: == Database Connection Pool == || Difficulty || Hard || Size. || 350hrs || Potential Mentors || Florian Apolloner, Carlton Gibson || Key Skills || Databases & ORM Django's persistent database connections [https://code.djangoproject.com/ticket/33497 do not function correctly under ASGI], for asynchronous code. As such we need a connection pool solution. There are per-database solutions out there, e.g. PG Bouncer for PostgreSQL, and psycopg — our PostgreSQL adapter provides [https://www.psycopg.org/psycopg3/docs/api/pool.html#psycopg-pool-connection-pool-implementations connection pooling]. Can we wrap those, or provide our own implementation if needed? There are other ORMs implementing similar, e.g. [http://docs.peewee-orm.com/en/latest/peewee/database.html?highlight=pool#connection-pooling the Peewee ORM's connection pooling]. What lessons can we learn there? A proposal here will show awareness of the prior art, and the difficulties involved. (Some background reading: https://github.com/brettwooldridge/HikariCP/blob/dev/documents/Welcome-To-The-Jungle.md and https://www.psycopg.org/articles/2021/01/17/pool-design/) Expected outcome would be a series of PRs, or iteration on a single PR, leading towards a connection pool implementation. The first stage would be a Proof-of-concept and high-level API design. Django's ORM supports multiple backends, so what would the exposed API look like. Can we then map that for each database. Then documenting the API, and highlighting any gotchas to be aware of in adoption. Final phase is ensure test coverage, and robustness of the implementation. There are always issues that come up with one backend or another that were not anticipated, so it's important to make good time getting to this point. == Auto-importing shell == || Difficulty || Medium || Size || 175hrs || Potential Mentors || Adam Johnson || Key Skills || Management commands One of the most popular features of django-extensions is `shell_plus`, which is like `shell` but auto-imports your models for you. Adding this behaviour to core would be a great addition. A proposal should consider ways to define extra things to import, perhaps a documented path of subclassing the management command and overriding a method. Expected outcome would be a PR adding this to Django. == Security: Bring CORS and CSP into core == || Difficulty || Medium || Size || 350hrs || Potential Mentors || Adam Johnson, James Bennett || Key Skills || HTTP request-response cycle, middleware, decorators There are third-party apps providing support for [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS Cross-Origin Resource Sharing (CORS)] `django-cors-headers` and [https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Content Security Policy (CSP)] `django-csp`, but it would be good to have support built-in to core. Following the design of the CSRF/clickjacking protection, having safe defaults, and allowing straightforward per-path customisation, via e.g. decorators, would improve the security of all Django projects. Outcome would be a pair of PRs adding these into Django. == Migrations == Here are a couple project ideas for improving Django's migrations framework. For both projects: || Difficulty || Hard. || Size || 350hrs || Potential Mentors || Shai Berger, Mariusz Felisiak || Key Skills || Migrations Framework === Moving models between apps === Support moving models between apps. In long-running projects you often end up needing to move a model between Django apps. It's not simple, and requires custom migration operations to perform. The Django [https://docs.djangoproject.com/en/4.1/howto/writing-migrations/#migrating-data-between-third-party-apps docs have some information on this] but there's a long-standing [https://code.djangoproject.com/ticket/24686 ticket to have the migration operations auto-generated]. Expected outcome would be a PR adding and documenting a migration operation to move a model between apps. === Auto-detection of custom migration operations === Allow auto-detection of custom migration operations. The auto-detector has its change-detection mostly hard-coded: [https://github.com/django/django/blob/main/django/db/migrations/autodetector.py#L104 autodetector.py#L104] It doesn't seem easy (or even possible with the current approach) to allow third-party code to intervene. The list of handlers to generated the individual operations would need to be data-driven, so that custom steps could be added. Expected outcome here would be a PR allowing auto-detection of custom migration operations. **Note**: These two projects are quite independent. Auto-detection of the fact that a model has moved between apps is not required, supporting such moves with flags to makemigrations or even a dedicated management-command would be completely satisfactory. == Improve the Database Cache Backend == || Difficulty || Medium. || Size || 350hrs || Potential Mentors|| Adam Johnson || Key Skills || Cache Framework Setting up a shared cache backend is nearly always required, as many third-party packages assume the cache works like this (unlike the default locmemcache which is per process). DatabaseCache is the easiest such cache backend, not requiring any extra infra and working on shared hosts without a filesystem. But it could be better. Django-Mysql has had a much better DB cache backend implementation since 2015: https://adamj.eu/tech/2015/05/17/building-a-better-databasecache-for-django-on-mysql/ . This has never been adapted for the other supported databases but it should be fairly straightforward, mostly some translation of SQL to different dialects. Expected outcome would be a PR improvement database cache backend. As a stretch goal, it would also be nice to hook the database cache tables into migrations somehow rather than the current hacky duck typing approach: https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/core/cache/backends/db.py#L12-L28 ). == Typed Django == There are several potential projects related to typing and the django-stubs project. For all three projects: || Difficulty || Hard. || Size || 175hrs || Potential Mentors || Adam Johnson || Key Skills || Python typing and Django-stubs === Strict-mode support for django-stubs === The django-stubs implementation does not currently pass Mypy’s strict mode. Making this compliant would enable users to always use strict mode with them, improving type safety. Expected outcome would be a PR doing that. === Merging django-types back into django-stubs === There is a spin-off project from django-stubs called django-types. The original intention here was for it to be merged back into django-stubs, but that's never happened. django-types removes the need to use any mypy plugins, making it possible to use type checkers other than mypy, such as Pyrite, Pyre, etc. django-types is not actively maintained, however, and having competing stubs implementations means neither is as strong as could be. There is a small project in extracting the work from django-types and creating a PR for django-stubs allowing it to be merged back in, and effort to be concentrated on the single implementation. === Exploratory proof-of-concept for typing Django core === Since type annotations were added to Python, there has been discussion of when and whether they should be added to Django. In 2019 a proposal to add inline type hints was rejected. (See https://github.com/django/deps/pull/65 and links therein.) Since then there has been improvements in the typing landscape, and more people in the community are using type hints regularly in their own projects. It remains difficult, though, to judge whether it's now time to reassess that earlier decision. An exploratory proof-of-concept project applying type hints to some of the //leaf// modules in Django (those without further dependencies) — perhaps utils, the forms widgets and into fields, or inside the SQL compiler of the ORM — would enable us to see what the decision to adopt inline type hints would amount to. Such a project would need to: - Add readable type-hints, making good use type alises, Protocols, and so on. - Configure mypy validation for the adjusted files, on CI, pre-commit, and for local development. - Add typing to the relevant tests cases, and apply type checking there too.   The goal would be a PR showing what an incremental adoption of inline typing would like for Django in 2023, to serve as the basis of a fresh discussion of whether to adopt typing more generally. == Configurable Content Type Parsing == || Difficulty || Medium. || Size || 350hrs || Potential Mentors || Carlton Gibson || Key Skills || HTTP request-response cycle For Django 5.0 we're looking to modernize the `HTTPRequest` object, adding a content-type aware `request.data` property. This will parse `request.body` according to the content type. The initial phase — targeted for before GSoC — will add `request.data` and add support for JSON body handling, but the next phase is to make that fully pluggable with custom parsers. - Add a list of parsers to the request object, that can be customised — in a middleware for example — at any point prior to accessing `request.data`. - Parsers should implement a `can_handle(content_type) -> Bool` method. The first parser returning True will be selected to parse the `request.body`. Expected outcome is a PR allowing configurable content type parsing. == Window expressions improvements == || Difficulty || Hard. || Size || 350hrs || Potential Mentors || Mariusz Felisiak, Simon Charette || Key Skills || ORM & SQL. There are a group of possible improvements to the Django ORM's handling of window expressions. In particular to add support for filtering against window expressions (see #28333), and for `EXCLUDE` and currently not covered `RowRange()` cases (see #29850). Expected outcome would be a PR on the ORM adding these features. == Database-level Cascades == || Difficulty || Medium || Size || 350hr || Possible mentors || Mariusz Felisiak, Simon Charette || Key Skills || ORM There's an old ticket to [https://code.djangoproject.com/ticket/21961 Add support for database-level cascading options]. This means that rather than Django's in-Python options for `on_delete` clauses, we'd allow the database to handle this with its native implementation. This would be a new option `db_on_delete` maybe, with the existing `on_delete` being `DO_NOTHING` if it were used. This had a couple of PRs that were in the right direction ([https://github.com/django/django/pull/14550 1], [https://github.com/django/django/pull/8661 2]), and [https://groups.google.com/g/django-developers/c/FJMoGgtYIX4/m/LTdjlWydJ2EJ a long-discussion on django-developers]. A effective first-pass here for a single database backend can be done creating a `ForeignKey` subclass setting a flag, and then overriding `DatabaseSchemaEditor` `add_field()` and `sql_create_fk()` to detect that, adjusting the generated SQL accordingly. (Try it!) The project would be to make that work generally, for all database backends, and integrate with the migrations framework. Would require knowledge of the Django ORM, SQL, and the supported database backends. Significant work has already gone into the project, so research of the links given would be needed. Expected outcome would be a PR adding support for Database-level Cascades to the Django ORM. == Add Async Support to Django Debug Toolbar == || Difficulty || Medium. || Size || 350hr || Possible mentors || Tim Schilling, Carlton Gibson || Key Skills || asyncio, ASGI & Channels, and django-debug-toolbar Django Debug Toolbar (DDT) is one of the key packages in the Django ecosystem. https://github.com/jazzband/django-debug-toolbar DDT is not yet compatibile with Django Channels and async Django run unders ASGI. Adding support for async to DDT would be a great contribution. Preliminary implementation ideas for this are available here: https://github.com/jazzband/django-debug-toolbar/pull/1432 Would require some knowledge of asyncio, Django Channels, ASGI, and how the Django Debug Toolbar works. Expected outcome would be a PR (or multiple PRs) moving the toolbar towards full compatibility with Django channels and async logic. == Or Create Your Own == We have around 900 accepted tickets on Django. Browse the issue tracker by component — here's an [https://code.djangoproject.com/query?status=assigned&status=new&component=contrib.staticfiles&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id example filter for contrib.staticfiles]. What's the bit of the framework that interests you? What contribution do you want to make to it? Use the tickets as guides here. Remember the advice above, that your project needs to be both on Django itself here, and achievable in the timescale of GSoC. Could be scoped as a 175hr or a 350hr project, depending on your idea. Possible mentors: ''Carlton Gibson'', ''Mariusz Felisiak''. We're open to all good ideas!