Changes between Version 11 and Version 12 of SummerOfCode2022

Timestamp:

Mar 1, 2022, 4:38:37 AM (3 years ago)

Author:

Carlton Gibson

Comment:

Expand project ideas

SummerOfCode2022

@@ -136 +136 @@
 Adapt schema editors to operate from model states instead of fake rendered models.
 
-This is [https://code.djangoproject.com/ticket/29898 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)
-
-Possible mentor: ''Mariusz Felisiak''.
+This is [https://code.djangoproject.com/ticket/29898 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''.
 
 == 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)
+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''.
@@ -168 +178 @@
 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 [https://code.djangoproject.com/ticket/32172 making signals async aware]). 
+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 [https://code.djangoproject.com/ticket/32172 making signals async aware]).
 The [https://github.com/django/channels/tree/main/loadtesting Channels project also has benchmarks that need updating].
 
-Creating a test harness using (say) [https://locust.io Locust.io] would make a great project. 
-
-(Likely medium difficulty. Could be scoped as a 175hr or a 350hr project)
+Creating a test harness using (say) [https://locust.io 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''.
@@ -187 +204 @@
 If you're interesting in this, open a discussion on the django-stubs repo or [https://gitter.im/mypy-django/Lobby the project chat].
 
-(Likely Hard project. Could be scoped as a 175hr or a 350hr project)
+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''.
@@ -195 +217 @@
 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 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].
-Adjusting `DatabaseSchemaEditor.sql_create_fk()` to be able to use the native options is the beginning. 
-
-(Hard project. 350hr project)
+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 == 
+== Per field-instance lookups ==
 
 There's a ticket to [https://code.djangoproject.com/ticket/29799 Allow registration and unregistration of lookups per field instances].
 
-You may want a [https://docs.djangoproject.com/en/4.0/howto/custom-lookups/ 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. 
-
-(Hard project. 350hr project)
-
-Possible mentor: ''Mariusz Felisiak''.
-
-== Add rate-limiting to core == 
-
-There's an old ticket [https://code.djangoproject.com/ticket/21289 Add login rate limiting to contrib.auth]. 
-There's a quite recent [https://github.com/django/django/pull/13242 WIP PR] that shows the way there. 
-
-Contrasting with the third-party [https://django-ratelimit.readthedocs.io/en/stable/index.html 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. 
-
-(Hard project. 350hr project)
+You may want a [https://docs.djangoproject.com/en/4.0/howto/custom-lookups/ 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 rate-limiting to core ==
+
+There's an old ticket [https://code.djangoproject.com/ticket/21289 Add login rate limiting to contrib.auth].
+There's a quite recent [https://github.com/django/django/pull/13242 WIP PR] that shows the way there.
+
+Contrasting with the third-party [https://django-ratelimit.readthedocs.io/en/stable/index.html 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''.