| Version 14 (modified by , 3 years ago) ( diff ) |
|---|
Google's Summer of Code 2022
Django is a mentor organization for the 2022 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 runs until April 19, 2022.
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 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:
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 django-developers and the 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 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 10-week timeline -- 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:
Migrations
Adapt schema editors to operate from model states instead of fake rendered models.
This is Ticket #29898. It's a big task overall, that was part of a successful GSoC project in 2021. Carrying-on and extending that work would be a great addition.
Hard project. 350hr project
Would require knowledge of the Django ORM, plus an investigation of the previous project, and discussions linked from that.
Expected outcome would be a PR (or a number of them) on the migrations framework.
Possible mentor: Mariusz Felisiak, Simon Charette, Manav Agarwal.
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.
Django Benchmarking
https://github.com/django/djangobench
Django has had a benchmarking suite for a while, but we've generally gotten 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.
Recent work has gone into [https://github.com/django/djangobench/issues/38 running the benchmarks regularly and integrating the Airspeed Velocity (ASV) package]. The task would be to help pick-up that work and bring the benchmarking up to the next level.
There's particular work in benchmarking the efforts to bring async to Django. It would be great to be able to see the effects of using ASGI (vs WSGI say), and of particular suggested changes (such as making signals async aware). The Channels project also has benchmarks that need updating.
Creating a test harness using (say) Locust.io would make a great project.
Likely medium difficulty. Could be scoped as a 175hr or a 350hr project
Would require some sys-admin knowledge to spin-up a testing harness and coordinate multiple services. Knowledge of GitHub Actions CI for integration would be useful.
Expected outcome would be improvements to the way in which we can the benchmarking suite, and ideally integration with the Django CI.
Possible mentor: David Smith.
Typed Django
After a successful GSoC project working on the mypy plugin in 2020, the `django-stubs` project is open to applications for this year.
django-stubs provides type annotation stub files that enables Django code to be checked with mypy, and other type checkers. Typing is gaining ground in Python, and you can help push forward its use in the Django ecosystem.
If you're interesting in this, open a discussion on the django-stubs repo or the project chat.
Likely Hard project. Could be scoped as a 175hr or a 350hr project
Would require knowledge of typing in Python, and the mypy project in-particular.
Expected outcome would be a PR (or series of PRs) to the django-stubs project, improving the typing support in Django.
Possible mentor: Nikita Sobolev.
Database-level Cascades
There's an old ticket to 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 (1, 2), and a long-discussion on django-developers.
Adjusting DatabaseSchemaEditor.sql_create_fk() to be able to use the native options is the beginning.
Medium project. 350hr project
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, and beneficial.
Expected outcome would be a PR adding support for Database-level Cascades to the Django ORM.
Possible mentor: Mariusz Felisiak.
Per field-instance lookups
There's a ticket to Allow registration and unregistration of lookups per field instances.
You may want a custom lookup not for every instance of a Field, but just this instance, on this model.
Implementing that would be a lovely addition to the ORM.
Medium project. 350hr project
Would require knowledge of the Django ORM, and the lookup API.
Expected outcome would be a PR adding support for per-field-instance lookups to the Django ORM.
Possible mentor: Mariusz Felisiak/Carlton Gibson.
Add Async Support to 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
Medium project. 350hr project
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.
Possible mentor: Tim Schilling/Carlton Gibson.
Add rate-limiting to core
There's an old ticket Add login rate limiting to contrib.auth. There's a quite recent WIP PR that shows the way there.
Contrasting with the third-party django-ratelimit to determine what's the appropriate scope for what we'd want in the core framework would be important, and a good source of stretch-goals.
Medium project. 350hr project
Would require knowledge of Django's HTTP layer, and middleware. Research into the existing PR and third-party package would be required, and beneficial.
Expected outcome would be a PR adding rate-limiting to Django.
Possible mentor: Carlton Gibson.
Or Create Your Own
We have over 1000 accepted tickets on Django. Browse the issue tracker by component — here's an 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)
Possible mentor: Carlton Gibson, Mariusz Felisiak.