Hi everyone,
I’m Khadyot Takale, a final-year engineering student from India, preparing for GSoC 2026.
Background:
- Python backend development (FastAPI, APIs, async workflows)
- Experience with REST APIs, databases, and production deployments
GitHub: KhadyotTakale · GitHub
Current focus:
I’m interested in contributing to Django’s template system and related components.
So far I have:
- Set up Django development environment locally
- Started exploring the template engine internals
- Reviewing relevant tickets on Trac
I’m planning to start with small fixes in this area and would appreciate suggestions for beginner-friendly tickets related to templates or rendering.
Looking forward to contributing!
1 Like
Welcome @KhadyotTakale !
We recommend that everyone gets started by reading:
Feel free to ask questions here if there’s anything in those references that you don’t understand or if you get stuck.
1 Like
Hi KhadyotTakale,
Interesting that you’re looking at the template system! I’ve been working on the
admin side — specifically keyboard shortcuts and accessibility improvements for
Django’s admin templates.
While working on the admin templates, I noticed that Django’s template system
handles things like `aria-` attributes and dynamic content well, but there’s no
standard pattern for accessibility-related template tags (like generating ``
elements for shortcut keys or `aria-live` regions).
Have you come across any accessibility-related areas in the template system during
your exploration? Would be curious to hear what you’ve found so far.
Good luck with your proposal!
Hi @prachisingh342006,
Thanks for the suggestion accessibility improvements in the admin sound like a really useful area.
While exploring Django internals I actually started by looking at the request handling side rather than the template system. I recently worked on a small fix related to ASGI request handling where the script_name prefix removal in ASGIRequest.__init__ could incorrectly strip prefixes when they weren’t proper path segment boundaries. That patch was merged recently.
I haven’t yet explored accessibility-related patterns in Django templates in depth, but your point about standardized template tags for things like shortcut hints or aria-live regions is interesting. I’ll definitely look more into how Django’s template system currently handles accessibility attributes and whether there are opportunities to improve that.
Thanks for bringing this up!
Hi Ken I have gone through the contribution guide and the GSoC ideas page and recently had my first Django PR merged (ticket #36940 – ASGI script prefix path handling). Right now I’m continuing with smaller fixes and TODOs to get more familiar with the codebase. still I would like to start thinking about a potential GSoC proposal. I am currently exploring areas around the Django admin and the template system. From a maintainer or community perspective, are there any known gaps or problems in these areas that might be worth developing into a larger proposal? I would prefer working on something the community actually needs rather than proposing something arbitrary.
Personally, I’m unable to help you with this. I’m not involved with the GSoC, and I don’t really know what would make for a good proposal.
That’s covered in the SummerOfCode2026 – Django page. There are some ideas presented along with suggestions for picking tickets from Trac.
Good luck!
That makes sense thanks One thing I have been curious about while exploring the codebase I noticed there are quite a few todos comments in different parts of Django. From what I understand the code works fine as it is so I was wondering what typically leads to these todos being left in place. Are they usually notes for future refactoring, architectural improvements that weren’t worth blocking the current change or things that depend on other parts of Django evolving first? Just trying to understand how maintainers think about these when working on a large project like Django.
Probably a mix of all-of-the-above. To try to understand the reasoning behind a particular “TODO”, you’d need to look at the ticket, the PR, and possibly messages here in the forum or the old Google group.
For one specific example, in .django.contrib.auth.management.__init__.get_system_username, you’ll find this:
# TODO: Drop ImportError and KeyError when dropping support for PY312.
I would categorize this as fitting into the “future refactoring” category. If you look, you can probably find examples of the others.
Got it that makes sense thanks for explaining Looking at the ticket/PR history around a TODO to understand the context is a good tip. I will start digging into those when I come across them while exploring the codebase.
I’ve been thinking more about this, and one area that seems interesting is how Django templates handle accessibility patterns inconsistently across components.
For example, while ARIA attributes are supported, there isn’t a standardized way to generate accessibility-related template structures (like shortcut hints or dynamic announcements).
Do you think introducing reusable template patterns or tags for accessibility could be a useful direction, or would it be better handled at the admin level instead?