Changes between Initial Version and Version 1 of SummerOfCode2023

Timestamp:

Jan 17, 2023, 8:44:17 AM (22 months ago)

Author:

Carlton Gibson

Comment:

Begin page for GSoC 2023

SummerOfCode2023

@@ +1 @@
+[[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 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 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 [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.
+
+In no particular order:
+
+== Database Connection Pool ==
+
+Difficulty: Hard
+Size:       350hrs
+Potential Mentors: "Florian Apolloner", "Carlton Gibson"
+
+Django's persistent database connections 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. Can we wrap those, or provide our own implementation if needed?
+
+A proposal here will show awareness of the prior art, and the difficulties involved. (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/)
+
+
+== Auto-importing shell ==
+
+Difficulty: Medium
+Size:       175hrs
+Potential Mentors: "Adam Johnson"
+
+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.
+
+
+== Security: Bring CORS and CSP into core ==
+
+Difficulty: Medium
+Size:       350hrs
+Potential Mentors: "Adam Johnson", "James Bennett"
+
+There are third-party apps providing support for Cross-Origin Resource Sharing (CORS) `django-cors-headers` and 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.
+
+== Migrations ==
+
+Here are a couple project ideas for improving Django's migrations framework.
+
+For both projects:
+
+Difficulty: Hard.
+Size:       350hrs
+Potential Mentors: "Shai Berger"
+
+=== Moving models between apps ===
+
+Support moving models between apps. This is a long-standing problem, esp. in
+enterprise-y or just long-running projects. It's not simple and requires custom
+migration operations to perform.
+
+It has been discussed previously:  https://forum.djangoproject.com/t/why-do-we-need-apps/827/20
+
+=== Audo-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
+
+It doesn't seem easy (or even possible with the current approach) to
+allow third-party code to intervene.
+
+A proposal here would need to demonstrate a plan for a route forward.
+
+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.
+
+
+- [SummerOfCode2022 (Edit) – Django](https://code.djangoproject.com/wiki/SummerOfCode2022?action=edit)
+- [WikiFormatting – Django](https://code.djangoproject.com/wiki/WikiFormatting)
+
+
+
+== Improve the Database Cache Backend ==
+
+Difficulty: Medium.
+Size:       350hrs
+Potential Mentors: "Adam Johnson"
+
+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.
+
+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"
+
+=== 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.
+
+=== 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"
+
+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`.
+
+
+== Window expressions improvements ==
+
+Add support for filtering against window expressions (see #28333), for `EXCLUDE` and currently not covered `RowRange()` cases (see #29850).
+
+Hard project. 350hr project
+
+Would require knowledge of the Django ORM, and the supported databases.
+
+Expected outcome would be a PR (or a number of them) on the ORM.
+
+Possible mentor: ''Mariusz Felisiak''.
+
+
+
+== Database-level Cascades ==
+
+Difficulty: Medium
+Size:       350hr
+Possible mentors: ''Mariusz Felisiak''.
+
+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 it's 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''.
+
+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''.