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 | |
| 132 | The 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 | |
| 134 | Outcome 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 | |
| 143 | The 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 | |
| 145 | Part 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 | |
| 147 | Outcome 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 | |
| 162 | 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. |
| 163 | |
| 164 | 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. |
| 165 | |
| 166 | Outcome 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 | |
| 175 | Allow auto-detection of custom migration operations. |
| 176 | |
| 177 | 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] |
| 178 | |
| 179 | It doesn't seem easy (or even possible with the current approach) to |
| 180 | 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. |
| 181 | |
| 182 | Expected 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 | |
| 191 | Setting up a shared cache backend is nearly always required, as many |
| 192 | third-party packages assume the cache works like this (unlike the default |
| 193 | locmemcache which is per process). DatabaseCache is the easiest such cache |
| 194 | backend, not requiring any extra infra and working on shared hosts without a |
| 195 | filesystem. But it could be better. |
| 196 | |
| 197 | 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. |
| 198 | |
| 199 | Expected outcome would be a PR improvement database cache backend. |
| 200 | |
| 201 | As a stretch goal, it would also be nice to hook the database cache tables into |
| 202 | migrations somehow rather than the current hacky duck typing approach: |
| 203 | https://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 | |
| 214 | django-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 | |
| 223 | 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. |
| 224 | |
| 225 | 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. |
| 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 | |
| 230 | Expected outcome is a PR allowing configurable content type parsing. |
| 231 | |