Changes between Version 1 and Version 2 of SummerOfCode2025


Ignore:
Timestamp:
Feb 11, 2025, 7:15:05 PM (20 hours ago)
Author:
Timothy Schilling
Comment:

Adding two confirmed projects and the other proposed projects that are still pending investigation.

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2025

    v1 v2  
    123123In no particular order:
    124124
    125 **Projects are still being finalized, the following is a placeholder template**
     125== Django Templates: Bring django-template-partials into core ==
     126
     127|| Difficulty || Medium
     128|| Size || 350hrs
     129|| Potential Mentors || Carlton Gibson
     130|| Key Skills || Django Template Language, template tags
     131
     132The third-party app django-template-partials allows for reusable named inline partials for the Django Template Language. These named inline partials can be used multiple times within a template or included in other templates. It would be good to have support built-in to core.
     133
     134Outcome would be a PR adding this into Django.
     135
     136== Automate processes within Django contribution workflow ==
     137
     138|| Difficulty || Medium
     139|| Size || 350hrs
     140|| Potential Mentors || Lily Foote
     141|| Key Skills || GitHub actions, scripting, Jenkins
     142
     143The contribution workflow within Django has several manual processes. These are error prone and take up valuable time from contributors. This project would seek to automate these processes, such as automating releases, identifying active PRs and managing aging PR queue.
     144
     145Part of this project will involve working with the Fellows to determine which of their tasks and the community's tasks are the best candidates for automation.
     146
     147Outcome would be one to several PRs automating these workflows, depending on how many are accomplished.
     148
     149
     150----
     151
     152**The following projects are still being finalized**
     153
     154
     155== Security: Bring CORS and CSP into core ==
     156
     157|| Difficulty || Medium
     158|| Size || 350hrs
     159|| Potential Mentors || TBC
     160|| Key Skills || HTTP request-response cycle, middleware, decorators
     161
     162There 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.
     163
     164Following 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.
     165
     166Outcome would be a pair of PRs adding these into Django.
     167
     168== Auto-detection of custom migration operations ==
     169
     170|| Difficulty || Hard.
     171|| Size || 350hrs
     172|| Potential Mentors || Mariusz Felisiak
     173|| Key Skills || Migrations Framework
     174
     175Allow auto-detection of custom migration operations.
     176
     177The 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]
     178
     179It doesn't seem easy (or even possible with the current approach) to
     180allow 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. 
     181
     182Expected outcome here would be a PR allowing auto-detection of custom migration operations.
     183
     184== Improve the Database Cache Backend ==
     185
     186|| Difficulty || Medium.
     187|| Size ||       350hrs
     188|| Potential Mentors|| TBC
     189|| Key Skills || Cache Framework
     190
     191Setting up a shared cache backend is nearly always required, as many
     192third-party packages assume the cache works like this (unlike the default
     193locmemcache which is per process). DatabaseCache is the easiest such cache
     194backend, not requiring any extra infra and working on shared hosts without a
     195filesystem. But it could be better.
     196
     197Django-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.
     198
     199Expected outcome would be a PR improvement database cache backend.
     200
     201As a stretch goal, it would also be nice to hook the database cache tables into
     202migrations somehow rather than the current hacky duck typing approach:
     203https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/core/cache/backends/db.py#L12-L28 ).
     204
     205== Expand django-stubs coverage ==
     206
     207|| Difficulty || Hard.
     208|| Size ||       Variable
     209|| Potential Mentors || Adam Johnson
     210|| Key Skills || Python typing and Django-stubs
     211
     212[https://github.com/typeddjango/django-stubs django-stubs] is an external project that adds type hints to Django. It may be possible to work on it under GSoC if you can show experience with Python’s type hints and Mypy.
     213
     214django-stubs uses Mypy’s stubtest tool to check that its type hints align with Django’s source, per [https://github.com/typeddjango/django-stubs/blob/master/CONTRIBUTING.md#testing-stubs-with-stubtest its contributing documentation]. The “todo” list contains ~1600 functions and classes missing type hints. A proposal targeting a specific, significant subset of the missing types is likely to be accepted.
     215
     216== Configurable Content Type Parsing ==
     217
     218|| Difficulty || Medium.
     219|| Size || 350hrs
     220|| Potential Mentors || TBC
     221|| Key Skills || HTTP request-response cycle
     222
     223For 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.
     224
     225The 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.
     226
     227- 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`.
     228- Parsers should implement a `can_handle(content_type) -> Bool` method. The first parser returning True will be selected to parse the `request.body`.
     229
     230Expected outcome is a PR allowing configurable content type parsing.
     231
    126232
    127233== [PLACEHOLDER] Project name ==
Back to Top