Changes between Initial Version and Version 1 of SummerOfCode2024

Timestamp:

Jan 9, 2024, 2:23:43 PM (11 months ago)

Author:

Mariusz Felisiak

Comment:

Initial page.

SummerOfCode2024

@@ +1 @@
+[[PageOutline]]
+= Google's Summer of Code 2024 =
+
+Django is a mentor organization for the 2024 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,
+Natalia Bidart 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 2, 2024.
+
+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 - `django-stubs` 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:
+
+== Auto-importing shell ==
+
+|| Difficulty || Medium
+|| Size ||       175hrs
+|| Potential Mentors || TBC
+|| 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 || TBC
+|| 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.
+
+=== Auto-detection of custom migration operations ===
+
+|| Difficulty || Hard.
+|| Size || 350hrs
+|| Potential Mentors || Mariusz Felisiak
+|| Key Skills || Migrations Framework
+
+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. 
+
+== Improve the Database Cache Backend ==
+
+|| Difficulty || Medium.
+|| Size ||       350hrs
+|| Potential Mentors|| TBC
+|| 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 || TBC
+|| 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.
+
+== Configurable Content Type Parsing ==
+
+|| Difficulty || Medium.
+|| Size || 350hrs
+|| Potential Mentors || TBC
+|| 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. 
+
+== Add Async Support to Django Debug Toolbar ==
+
+|| Difficulty || Medium.
+|| Size ||       350hr
+|| Possible mentors || Tim Schilling
+|| 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: ''Natalia Bidart'', ''Mariusz Felisiak''.
+
+We're open to all good ideas!