When we learned that the Django Software Foundation has been accepted as a mentoring organization for Google Summer of Code 2026, it marked another steady milestone in a long-standing relationship. Django first participated in GSoC in 2006, and 2026 represents our 21st consecutive year in the program. Over two decades, GSoC has become a consistent pathway for contributors to engage more deeply with Django — not just through a summer project, but often through continued involvement that extends well beyond the official coding period. For many of you reading this, this might be your first exposure to how Django’s open source ecosystem works. So before we get into applications and expectations, let’s take a step back and understand the environment you’re stepping into. Understanding the Django Ecosystem The Django Software Foundation (DSF) is the non-profit organization that supports the long-term sustainability of Django. Django itself is developed entirely in the open. Feature discussions, architectural debates, bug reports, design proposals, and code reviews all happen publicly. That openness is intentional. It allows anyone, from anywhere in the world, to participate. But it also means decisions are rarely made quickly or casually. Changes are discussed carefully. Trade-offs are evaluated. Backwards compatibility is taken seriously. If you are new, it helps to understand the main spaces where this work happens: The Django Forum is where broader discussions take place — new feature ideas, design direction, and community conversations. Django Trac is the issue tracker, where bugs, feature requests, and patches are formally recorded and reviewed. If no one is working on an issue, you can assign it yourself and start working on it. Code contributions happen through pull requests, where proposed changes are reviewed, tested, and discussed in detail before being merged. New features are proposed and discussed in the new-features repository. There is a project board view that shows the state of each proposal. For someone new, this ecosystem can feel overwhelming at first. Threads may reference decisions made years ago. Review comments can be detailed. Standards are high. That is precisely why GSoC matters to us. It provides a structured entry point into this culture, with mentorship and guidance along the way, helping contributors understand not just how to write code — but how Django evolves. Why the Django Forum Is Central Most GSoC journeys in Django begin on the Django Forum — the community’s public space for technical discussions about features, design decisions, and improvements to Django. Introducing yourself there is not a formality; it is often your first real contribution. When you discuss a project idea publicly, you demonstrate how you think, how you respond to feedback, and how you handle technical trade-offs. Questions and challenges from mentors are not barriers — they are part of the collaborative design process. Proposals that grow through open discussion on the Forum are almost always stronger than those written in isolation. What To Do If you are planning to apply for GSoC 2026 with Django, here is what we strongly encourage: Start early. Do not wait until the application window opens. Begin discussions well in advance. Engage publicly. Introduce yourself on the Forum. Participate in ongoing threads. Show consistent involvement rather than one-time activity. Demonstrate understanding(very important) Read related tickets and past discussions. Reference them in your proposal. Show that you understand the technical and philosophical context. Be realistic about scope. Ambitious ideas are welcome, but they must be grounded in technical feasibility within the GSoC timeframe. Show iteration. If your proposal evolves because of feedback, that is a positive signal. It shows adaptability and thoughtful engagement. What Not To Do Equally important are the expectations around what we will not consider. Do not submit a proposal without prior discussion. A proposal that appears for the first time in the application form, without any Forum engagement, will be at a disadvantage. Do not generate a proposal using AI and submit it as-is. If a proposal is clearly AI-generated, lacks discussion history, and shows no evidence of personal understanding, it will be rejected. We evaluate your reasoning process, not just the surface quality of the document. Do not copy previous proposals. Each year’s context is different. We expect original thinking and up-to-date understanding. Do not treat GSoC as a solo internship. Django development is collaborative. If you are uncomfortable discussing ideas publicly or receiving detailed feedback, this may not be the right fit. Do not submit empty or placeholder proposal documents. In previous years, we have received blank or near-empty submissions, which create unnecessary effort for volunteer reviewers. Such proposals will not be considered. Do not repeatedly tag or ping maintainers for reviews. Once you’ve submitted your proposal or patch, give reviewers time to respond. Maintainers are volunteers managing many responsibilities, and repeated tagging does not speed up the process. Patience and respectful follow-ups (after a reasonable interval) are appreciated. On AI Usage We recognize that AI tools are now part of many developers’ workflows. Using AI to explore documentation, clarify syntax, or organize thoughts is not inherently a problem. However, AI must not replace ownership. You should be able to clearly explain your architectural decisions, justify trade-offs, and respond thoughtfully when challenged. If you cannot defend your own proposal without external assistance, it signals a lack of readiness for this kind of work. The quality we look for is not perfect language — it is depth of understanding. I’m a First-Time Contributor to Django — What Should I Do? If this is your first time contributing to Django, start simple and start early. First, spend some time understanding how Django works as an open source project. Read a few recent discussions on the Django Forum and browse open tickets to see the kinds of problems being discussed. Next, introduce yourself on the Forum. Share your background briefly and mention what areas interest you. You don’t need to have a perfect project idea on day one — curiosity and willingness to learn matter more. Then: Read the official first time contributor guide carefully. Try setting up Django locally and run the test suite. Look for small tickets on trac (including documentation or cleanup tasks) to understand the workflow. Ask questions on the Forum or in Discord if something is unclear. Most importantly, be patient with yourself. Django is a mature and widely used framework, and it takes time to understand its design principles and contribution standards. Strong contributors are not the ones who know everything at the start — they are the ones who show up consistently, engage thoughtfully, and improve through feedback. To conclude We are excited to welcome a new group of contributors into the Django ecosystem through Google Summer of Code 2026. We look forward to thoughtful ideas, constructive discussions, and a summer of meaningful collaboration — built not just on code, but on understanding and shared responsibility.

For February 2026, we welcome Baptiste Mispelon as our DSF member of the month! ⭐ Photo by Bartek Pawlik - bartpawlik.format.com Baptiste is a long-time Django and Python contributor who co-created the Django Under the Hood conference series and serves on the Ops team maintaining its infrastructure. He has been a DSF member since November 2014. You can learn more about Baptiste by visiting Baptiste's website and his GitHub Profile. Let’s spend some time getting to know Baptiste better! Can you tell us a little about yourself? (hobbies, education, etc) I'm a French immigrant living in Norway. In the day time I work as software engineer at Torchbox building Django and Wagtail sites. Education-wise I'm a "self-taught" (whatever that means) developer and started working when I was very young. In terms of hobbies, I'm a big language nerd and I'm always up for a good etymology fact. I also enjoy the outdoor whether it's on a mountain bike or on foot (still not convinced by this skiing thing they do in Norway, but I'm trying). How did you start using Django? I was working in a startup where I had built an unmaintainable pile of custom framework-less PHP code. I'd heard of this cool Python framework and thought it would help me bring some structure to our codebase. So I started rewriting our services bit-by-bit and eventually switched everything to Django after about a year. In 2012, I bought a ticket to DjangoCon Europe in Zurich and went there not knowing anyone. It was one of the best decisions of my life: the Django community welcomed me and has given me so much over the years. What other framework do you know and if there is anything you would like to have in Django if you had magical powers? I've been making website for more than two decades now, so I've used my fair share of various technologies and frameworks, but Django is still my "daily driver" and the one I like the best. I like writing plain CSS, and when I need some extra bit of JS I like to use Alpine JS and/or HTMX: I find they work really well together with Django. If I had magical powers and could change anything, I would remove the word "patch" from existence (and especially from the Django documentation). What projects are you working on now? I don't have any big projects active at the moment, I'm mostly working on client projects at work. Which Django libraries are your favorite (core or 3rd party)? My favorite Django library of all time is possibly django-admin-dracula. It's the perfect combination of professional and whimsical for me. Other than that I'm also a big fan of the Wagtail CMS. I've been learning more and more about it in the past year and I've really been liking it. The code feels very Django-y and the community around it is lovely as well. What are the top three things in Django that you like? 1) First of course is the people. I know it's a cliche but the community is what makes Django so special. 2) In terms of the framework, what brought me to it in the first place was its opinionated structure and settings. When I started working with Django I didn't really know much about web development, but Django's standard project structure and excellent defaults meant that I could just use things out of the box knowing I was building something solid. And more than that, as my skills and knowledge grew I was able to swap out those defaults with some more custom things that worked better for me. There's room to grow and the transition has always felt very smooth for me. 3) And if I had to pick a single feature, then I'd go for one that I think is underrated: assertQuerySetEqual(). I think more people should be using it! What is it like to be in the Ops team? It's both very exciting and very boring 😅 Most of the tasks we do are very mundane: create DNS records, update a server, deploy a fix. But because we have access and control over a big part of the infrastructure that powers the Django community, it's also a big responsibility which we don't take lightly. I know you were one of the first members of the Django Girls Foundation board of directors. That's amazing! How did that start for you? By 2014 I'd become good friend with Ola & Ola and in July they asked me to be a coach at the very first Django Girls workshop at EuroPython in Berlin. The energy at that event was amazing an unlike any other event I'd been a part of, so I got hooked. I went on to coach at many other workshops after that. When Ola & Ola had the idea to start an official entity for Django Girls, they needed a token white guy and I gladly accepted the role! You co-created Django Under the Hood series which, from what I've heard, was very successful at the time. Can you tell us a little more about this conference and its beginnings? I'm still really proud of having been on that team and of what we achieved with this conference. So many stories to tell! I believe it all started at the Django Village conference where Marc Tamlin and I were looking for ideas for how to bring the Django core team together. We thought that having a conference would be a good way to give an excuse (and raise funds) for people to travel all to the same place and work on Django. Somehow we decided that Amsterdam was the perfect place for that. Then we were extremely lucky that a bunch of talented folks actually turned that idea into a reality: Sasha, Ola, Tomek, Ola, Remco, Kasia (and many others) 💖. As a former conference organizer and volunteer, do you have any recommendations for those who want to contribute or organize a conference? I think our industry (and even the world in general) is in a very different place today than a decade ago when I was actively organizing conferences. Honestly I'm not sure it would be as easy today to do the things we've done. My recommendation is to do it if you can. I've forged some real friendships in my time as an organizer, and as exhausting and stressful as it can be, it's also immensely rewarding in its own way. The hard lesson I'd also give is that you should pay attention to who gets to come to your events, and more importantly who doesn't. Organizing a conference is essentially making a million decisions, most of which are really boring. But every decision you make has an effect when it's combined with all the others. The food you serve or don't serve, the time of year your event takes place, its location. Whether you spend your budget on fun tshirts, or on travel grants. All of it makes a difference somehow. Do you remember your first contribution in Django? I do! It was commit ac8eb82abb23f7ae50ab85100619f13257b03526: a one character typo fix in an error message 😂 Is there anything else you’d like to say? Open source is made of people, not code. You'll never go wrong by investing in your community. Claude will never love you back. Thank you for doing the interview, Baptiste !

Last month we announced our plan to adopt Contributor Covenant 3 as Django's new Code of Conduct through a multi-step process. Today we're excited to share that we've completed the first step of that journey! What We've Done We've merged new documentation that outlines how any member of the Django community can propose changes to our Code of Conduct and related policies. This creates a transparent, community-driven process for keeping our policies current and relevant. The new process includes: Proposing Changes: Anyone can open an issue with a clear description of their proposed change and the rationale behind it. Community Review: The Code of Conduct Working Group will discuss proposals in our monthly meetings and may solicit broader community feedback through the forum, Discord, or DSF Slack. Approval and Announcement: Once consensus is reached, changes are merged and announced to the community. Changes to the Code of Conduct itself will be sent to the DSF Board for final approval. How You Can Get Involved We welcome and encourage participation from everyone in the Django community! Here's how you can engage with this process: Share Your Ideas: If you have suggestions for improving our Code of Conduct or related documentation, open an issue on our GitHub repo. Join the Discussion: Participate in community discussions about proposed changes on the forum, Discord, or DSF Slack. Keep it positive, constructive, and respectful. Stay Informed: Watch the Code of Conduct repository to follow along with proposed changes and discussions. Provide Feedback: Not comfortable with GitHub? You can also reach out via conduct@djangoproject.com, or look for anyone with the Code of Conduct WG role on Discord. What's Next We're moving forward with the remaining steps of our plan: Step 2 (target: March 15): Update our Enforcement Manual, Reporting Guidelines, and FAQs via pull request 91. Step 3 (target: April 15): Adopt the Contributor Covenant 3 with proposed changes from the working group. Each step will have its own pull request where the community can review and provide feedback before we merge. We're committed to taking the time needed to incorporate your input thoughtfully. Thank you for being part of this important work to make Django a more welcoming and inclusive community for everyone!

The members of the Steering Council wanted to provide you all with a quick TL;DR of our work in 2025. First off, we were elected at the end of 2024 and got started in earnest in early 2025 with the mission to revive and dramatically increase the role of the Steering Council. We're meeting for a video conference at least monthly, you can deep dive into the meeting notes to see what we've been up to. We also have set up Slack channels we use to communicate in between meetings to keep action items moving along. One of the first things we did was temporarily suspend much of the process around DEP 10. Its heart is in the right place, but it's just too complex and cumbersome day-to-day with a primarily volunteer organization. We're slowly making progress on a revamped and simplified process that addresses our concerns. It is our goal to finish this before our terms expire. New Features Process We've moved the process for proposing new features out of the Django Forum and mailing lists to new-features Github repository. We made this change for a variety of reasons, but the largest being to reduce the workload for the Django Fellows in shepherding the process and answering related questions. Community Ecosystem Page One of our main goals is to increase the visibility of the amazing Django third-party package ecosystem. Long time Django users know which packages to use, which you can trust, and which ones may be perfect for certain use cases. However, MANY newer or more casual Django users are often unaware of these great tools and not sure where to even begin. As a first step, we've added the Community Ecosystem page which highlights several amazing resources to keep in touch with what is going on with Django, how to find recommended packages, and a sample list of those packages the Steering Council itself recommends and uses frequently. Administrative bits There has been work on better formalizing and documenting our processes and building documentation to make it much easier for the next Steering Council members. There has also been fair bit of work around helping organize Google Summer of Code participants to help ensure the projects undertaken are ones that will ultimately be accepted smoothly into Django. Another area we have focused on is a simplified DEP process. We're still formalizing this, but the idea is to have the Steering Council do the majority of the heavy lifting on writing these and in a format that is shorter/simpler to reduce the friction of creating larger more complicated DEPs. We have also been in discussions with various third parties about acquiring funding for some of the new features and updates on the horizon. It's been a productive year and we're aiming to have 2026 be as productive if not more so. We're still setting all of our 2026 goals and will report on those soon. Please reach out to the Steering Council directly if you have any questions or concerns.

Yesterday, Django issued security releases mitigating six vulnerabilities of varying severity. Django is a secure web framework, and that hasn’t changed. What feels new is the remarkable consistency across the reports we receive now. Almost every report now is a variation on a prior vulnerability. Instead of uncovering new classes of issues, these reports explore how an underlying pattern from a recent advisory might surface in a similar code path or under a slightly different configuration. These reports are often technically plausible but only sometimes worth fixing. Over time, this has shifted the Security Team’s work away from discovery towards deciding how far a given precedent should extend and whether the impact of the marginal variation rises to the level of a vulnerability. Take yesterday’s releases: We patched a “low” severity user enumeration vulnerability in the mod_wsgi authentication handler (CVE 2025-13473). It’s a straightforward variation on CVE 2024-39329, which affected authentication more generally. We also patched two potential denial-of-service vulnerabilities when handling large, malformed inputs. One exploits inefficient string concatenation in header parsing under ASGI (CVE 2025-14550). Concatenating strings in a loop is known to be slow, and we’ve done fixes in public where the impact is low. The other one (CVE 2026-1285) exploits deeply nested entities. December’s vulnerability in the XML serializer (CVE 2025-64460) was about those very two themes. Finally, we also patched three potential SQL injection vulnerabilities. One envisioned a developer passing unsanitized user input to a niche feature of the PostGIS backend (CVE 2026-1207), much like CVE 2020-9402. Our security reporting policy assumes that developers are aware of the risks when passing unsanitized user input directly to the ORM. But the division between SQL statements and parameters is well ingrained, and the expectation is that Django will not fail to escape parameters. The last two vulnerabilities (CVE 2026-1287 and CVE 2026-1312) targeted user-controlled column aliases, the latest in a stream of reports stemming from CVE 2022-28346, involving unpacking **kwargs into .filter() and friends, including four security releases in a row in late 2025. You might ask, “who would unpack **kwargs into the ORM?!” But imagine letting users name aggregations in configurable reports. You would have something more like a parameter, and so you would appreciate some protection against crafted inputs. On top of all that, on a nearly daily basis we get reports duplicating other pending reports, or even reports about vulnerabilities that have already been fixed and publicized. Clearly, reporters are using LLMs to generate (initially) plausible variations. Security releases come with costs to the community. They interrupt our users’ development workflows, and they also severely interrupt ours. There are alternatives. The long tail of reports about user-controlled aliases presents an obvious one: we can just re-architect that area. (Thanks to Simon Charette for a pull request doing just that!) Beyond that, there are more drastic alternatives. We can confirm fewer vulnerabilities by placing a higher value on a user's duty to validate inputs, placing a lower value on our prior precedents, or fixing lower severity issues publicly. The risk there is underreacting, or seeing our development workflow disrupted anyway when a decision not to confirm a vulnerability is challenged. Reporters are clearly benefiting from our commitment to being consistent. For the moment, the Security Team hopes that reacting in a consistent way—even if it means sometimes issuing six patches—outweighs the cost of the security process. It’s something we’re weighing. As always, keep the responsibly vetted reports coming to security@djangoproject.com.

In accordance with our security release policy, the Django team is issuing releases for Django 6.0.2, Django 5.2.11, and Django 4.2.28. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as possible. CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler The django.contrib.auth.handlers.modwsgi.check_password() function for authentication via mod_wsgi allowed remote attackers to enumerate users via a timing attack. Thanks to Stackered for the report. This issue has severity "low" according to the Django security policy. CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI When receiving duplicates of a single header, ASGIRequest allowed a remote attacker to cause a potential denial-of-service via a specifically created request with multiple duplicate headers. The vulnerability resulted from repeated string concatenation while combining repeated headers, which produced super-linear computation resulting in service degradation or outage. Thanks to Jiyong Yang for the report. This issue has severity "moderate" according to the Django security policy. CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS Raster lookups on GIS fields (only implemented on PostGIS) were subject to SQL injection if untrusted data was used as a band index. As a reminder, all untrusted user input should be validated before use. Thanks to Tarek Nakkouch for the report. This issue has severity "high" according to the Django security policy. CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True) and truncatechars_html and truncatewords_html template filters were subject to a potential denial-of-service attack via certain inputs with a large number of unmatched HTML end tags, which could cause quadratic time complexity during HTML parsing. Thanks to Seokchan Yoon for the report. This issue has severity "moderate" according to the Django security policy. CVE-2026-1287: Potential SQL injection in column aliases via control characters FilteredRelation was subject to SQL injection in column aliases via control characters, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias(). Thanks to Solomon Kebede for the report. This issue has severity "high" according to the Django security policy. CVE-2026-1312: Potential SQL injection via QuerySet.order_by and FilteredRelation QuerySet.order_by() was subject to SQL injection in column aliases containing periods when the same alias was, using a suitably crafted dictionary, with dictionary expansion, used in FilteredRelation. Thanks to Solomon Kebede for the report. This issue has severity "high" according to the Django security policy. Affected supported versions Django main Django 6.0 Django 5.2 Django 4.2 Resolution Patches to resolve the issue have been applied to Django's main, 6.0, 5.2, and 4.2 branches. The patches may be obtained from the following changesets. CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2025-14550: Potential denial-of-service vulnerability via repeated headers when using ASGI On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1207: Potential SQL injection via raster lookups on PostGIS On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1285: Potential denial-of-service vulnerability in django.utils.text.Truncator HTML methods On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1287: Potential SQL injection in column aliases via control characters On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch CVE-2026-1312: Potential SQL injection via QuerySet.order_by and FilteredRelation On the main branch On the 6.0 branch On the 5.2 branch On the 4.2 branch The following releases have been issued Django 6.0.2 (download Django 6.0.2 | 6.0.2 checksums) Django 5.2.11 (download Django 5.2.11 | 5.2.11 checksums) Django 4.2.28 (download Django 4.2.28 | 4.2.28 checksums) The PGP key ID used for this release is Jacob Walls: 131403F4D16D8DC7 General notes regarding security reporting As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information.

We are thrilled to announce that Djangonaut Space, a mentorship program for contributing to Django, is open for applicants for our next cohort! 🚀 Djangonaut Space is holding a sixth session! This session will start on March 2nd, 2026. We are currently accepting applications until February 2nd, 2026 Anywhere on Earth. More details can be found in the website. Djangonaut Space is a free, 8-week group mentoring program where individuals will work self-paced in a semi-structured learning environment. It seeks to help members of the community who wish to level up their current Django code contributions and potentially take on leadership roles in Django in the future. “I'm so grateful to have been a part of the Djangonaut Space program. It's a wonderfully warm, diverse, and welcoming space, and the perfect place to get started with Django contributions. The community is full of bright, talented individuals who are making time to help and guide others, which is truly a joy to experience. Before Djangonaut Space, I felt as though I wasn't the kind of person who could become a Django contributor; now I feel like I found a place where I belong.” - Eliana, Djangonaut Session 1 Enthusiastic about contributing to Django but wondering what we have in store for you? No worries, we have got you covered! 🤝 ✏️ Mission Briefing 📷 AMA Recap

For January 2026, we welcome Omar Abou Mrad as our DSF member of the month! ⭐ Omar is a helper in the Django Discord server, he has helped and continuously help folks around the world in their Django journey! He is part of the Discord Staff Team. He has been a DSF member since June 2024. You can learn more about Omar by visiting Omar's website and his GitHub Profile. Let’s spend some time getting to know Omar better! Can you tell us a little about yourself? (hobbies, education, etc) Hello! My name is Omar Abou Mrad, a 47-year-old husband to a beautiful wife and father of three teenage boys. I’m from Lebanon (Middle East), have a Computer Science background, and currently work as a Technical Lead on a day-to-day basis. I’m mostly high on life and quite enthusiastic about technology, sports, food, and much more! I love learning new things and I love helping people. Most of my friends, acquaintances, and generally people online know me as Xterm. I have already an idea but where your nickname "Xterm" comes from? xterm is simply the terminal emulator for the X Window System. I first encountered it back in the mid to late 90s when I started using Redhat 2.0 operating system. Things weren’t easy to set up back then, and the terminal was where you spent most of your time. Nevertheless, I had to wait months (or was it years?) on end for the nickname "Xterm" to expire on Freenode back in mid 2000s, before I snatched and registered it. Alas, I did! Xterm, c'est moi! >:-] How did you start using Django? We landed on Django (~1.1) fairly early at work, as we wanted to use Python with an ORM while building websites for different clients. The real challenge came when we took on a project responsible for managing operations, traceability, and reporting at a pipe-manufacturing company. By that time, most of the team was already well-versed in Django (~1.6), and we went head-on into building one of the most complicated applications we had done to date, everything from the back office to operators’ devices connected to a Django-powered system. Since then, most of our projects have been built with Django at the core. We love Django. What other framework do you know and if there is anything you would like to have in Django if you had magical powers? I've used a multitude of frameworks professionally before Django, primarily in Java (EE, SeamFramework, ...) and .NET (ASP.NET, ASP.NET MVC) as well as sampling different frameworks for educational purposes. I suppose if I could snap my fingers and get things to exist in django it wouldn't be something new as much as it is official support of: Built-in and opinionated way to deal with hierarchical data in the ORM alongside the supporting API for building and traversing them optimally. Built-in websockets support. Essentially the django-channel experience. Built-in ORM support for common constructs like CTEs, and possibly the ability to transition from raw SQL into a queryset pipeline. But since we're finger-snapping things to existence, it would be awesome if every component of django (core, orm, templates, forms, "all") could be installed separately in such a way that you could cherry pick what you want to install, so we could dismiss those pesky (cough) arguments (cough) about Django being bulky. What projects are you working on now? I'm involved in numerous projects currently at work, most of which are based on Django, but the one I'm working right now consists of doing integrations and synchronizations with SAP HANA for different modules, in different applications. It's quite the challenge, which makes it twice the fun. Which Django libraries are your favorite (core or 3rd party)? django-debug-toolbar hands down. It is an absolute beast of a library and a required tool. It is also the lib that influenced DryORM django-extensions obviously, for its numerous helper commands (shell_plus --print-sql, runserver_plus... and much more!) django-mptt while unmaintained, it remains one of my personal favorites for hierarchical data. It's a true piece of art. I would like to mention that I'm extremely thankful for any and all core and 3rd Party libraries out there! What are the top three things in Django that you like? In no particular order: The ORM; We love it, it fits nicely with the rest of the components. I feel we should not dismiss what sets Django apart from most frameworks; Its defaults, the conventions, and how opinionated it is; If you avoid overriding the defaults that you get, you'll end up with a codebase that anyone can read, understand and maintain easily. (This is quite subjective and some may very well disagree! ^.^) The documentation. Django’s documentation is among the best out there: comprehensive, exhaustive, and incredibly well written. You are helping a lot of folks in Django Discord, what do you think is needed to be a good helper according to you? First and foremost, I want to highlight what an excellent staff team we have on the Official Django Discord. While I don’t feel I hold a candle to what the rest of the team does daily, we complement each other very well. To me, being a good helper means: Having patience. You’ve built skills over many years, and not everyone is at the same stage. People will ask unreasonable or incorrect questions, and sometimes they simply won’t listen. Guiding people toward figuring things out themselves. Giving a direct solution rarely helps in the long run. There are no scoreboards when it comes to helping others. Teaching how to break problems down and reduce noise, especially how to produce the bare minimum code needed to reproduce an issue. Point them to the official documentation first, and teaching them how to find answers. Staying humble. No one knows everything, and you can always learn from your peers. Dry ORM is really appreciated! What motivated you to create the project? Imagine you're having a discussion with a djangonaut friend or colleague about some data modeling, or answering some question or concern they have, or reviewing some ORM code in a repository on github, or helping someone on IRC, Slack, Discord, the forums... or simply you want to do some quick ORM experiment but not disturb your current project. The most common ways people deal with this, is by having a throw-away project that they add models to, generate migrations, open the shell, run the queries they want, reset the db if needed, copy the models and the shell code into some code sharing site, then send the link to the recipient. Not to mention needing to store the code they experiment with in either separate scripts or management commands so they can have them as references for later. I loved what DDT gave me with the queries transparency, I loved experimenting in the shell with shell_plus --print-sql and I needed to share things online. All of this was cumbersome and that’s when DryORM came into existence, simplifying the entire process into a single code snippet. The need grew massively when I became a helper on Official Django Discord and noticed we (Staff) could greatly benefit from having this tool not only to assist others, but share knowledge among ourselves. While I never truly wanted to go public with it, I was encouraged by my peers on Discord to share it and since then, they've been extremely supportive and assisted in its evolution. The unexpected thing however, was for DryORM to be used in the official code tracker, or the forums, or even in Github PRs! Ever since, I've decided to put a lot of focus and effort on having features that can support the django contributors in their quest evolve Django. So here's a shout-out to everyone that use DryORM! I believe you are the main maintainer, do you need help on something? Yes, I am and thank you! I think the application has reached a point where new feature releases will slow down, so it’s entering more of a maintenance phase now, which I can manage. Hopefully soon we'll have the discord bot executing ORM snippet :-] What are your hobbies or what do you do when you’re not working? Oh wow, not working, what's that like! :-] Early mornings are usually reserved for weight training.\ Followed by a long, full workday.\ Then escorting and watching the kids at practice.\ Evenings are spent with my wife.\ Late nights are either light gaming or some tech-related reading and prototyping.\ Weekends look very similar, just with many more kids sports matches! Is there anything else you’d like to say? I want to thank everyone who helped make Django what it is today. If you’re reading this and aren’t yet part of the Discord community, I invite you to join us! You’ll find many like-minded people to discuss your interests with. Whether you’re there to help, get help, or just hang around, it’s a fun place to be. Thank you for doing the interview, Omar!

Today we've issued the 5.2.10 and 6.0.1 bugfix releases. The release packages and checksums are available from our downloads page, as well as from the Python Package Index. The PGP key ID used for these releases is Jacob Walls: 131403F4D16D8DC7

For December 2025, we welcome Clifford Gama as our DSF member of the month! ⭐ Clifford contributed to Django core with more than 5 PRs merged in few months! He is part of the Triage and Review Team. He has been a DSF member since October 2024. You can learn more about Clifford by visiting Clifford's website and his GitHub Profile. Let’s spend some time getting to know Clifford better! Can you tell us a little about yourself (hobbies, education, etc) I'm Clifford. I hold a Bachelor's degree in Mechanical Engineering from the University of Zimbabwe. How did you start using Django? During my first year in college, I was also exploring open online courses on EDx and I came across CS50's introduction to web development. After watching the introductory lecture -- which introduced me to git and GitHub -- I discovered Django's excellent documentation and got started on the polls tutorial. The docs were so comprehensive and helpful I never felt the need to return to CS50. (I generally prefer comprehensive first-hand, written learning material over summaries and videos.) At the time, I had already experimented with flask, but I guess mainly because I didn't know SQL and because flask didn't have an ORM, I never quite picked it up. With Django I felt like I was taking a learning fast-track where I'd learn everything I needed in one go! And that's how I started using Django. What projects are you working on now? At the moment, I’ve been focusing on improving my core skills in preparation for remote work, so I haven’t been starting new projects because of that. That said, I’ve been working on a client project involving generating large, image-heavy PDFs with WeasyPrint, where I’ve been investigating performance bottlenecks and ways to speed up generation time, which was previously around 30 minutes 😱. What are you learning about these days? I’ve been reading Boost Your Git DX by Adam Johnson and learning how to boost my Git and shell developer experience, which has been a great read. Aside from that, inspired by some blogs and talks by Haki Benita, I am also learning about software design and performance. Additionally, I am working on improving my general fluency in Python. What other framework do you know and if there is anything you would like to have in Django if you had magical powers? I am not familiar with any other frameworks, but if I had magic powers I'd add production-grade static-file serving in Django. Django libraries are your favorite (core or 3rd party)? The ORM, Wagtail and Django's admin. What are the top three things in Django that you like? The community The documentation Djangonaut Space and the way new contributors are welcomed How did you start contributing to Django? I started contributing to Django in August last year, which is when I discovered the community, which was a real game changer for me. Python was my first course at university, and I loved it because it was creative and there was no limit to what I could build with it. Whenever I saw a problem in another course that could be solved programmatically, I jumped at it. My proudest project from that time was building an NxN matrix determinant calculator after learning about recursion and spotting the opportunity in an algebra class. After COVID lockdown, I gave programming up for a while. With more time on my hands, I found myself prioritizing programming over core courses, so I took a break. Last year, I returned to it when I faced a problem that I could only solve with Django. My goal was simply to build an app quickly and go back to being a non-programmer, but along the way I thought I found a bug in Django, filed a ticket, and ended up writing a documentation PR. That’s when I really discovered the Django community. What attracted me most was that contributions are held to high standards, but experienced developers are always ready to help you reach them. Contributing was collaborative, pushing everyone to do their best. It was a learning opportunity too good to pass up. How did you join the Triage and Review team? About the time after I contributed my first PR, I started looking at open tickets to find more to work on, and keep on learning. Sometimes a ticket was awaiting triage, in which case the first step was to triage it before assigning it to working on it, and sometimes the ticket I wanted was already taken, in which case I'd look at the PR if available. Reviewing a PR can be a faster way to learn about a particular part of the codebase, because someone has already done most of the investigative part of work, so I reviewed PRs as well. After a while I got an invitation from Sarah Boyce, one of the fellows, to join the team. I didn't even know that I could join before I got the invitation, so I was thrilled! How the work is going so far? It’s been rewarding. I’ve gained familiarity with the Django codebase and real experience collaborating with others, which already exceeds what I expected when I started contributing. One unexpected highlight was forming a friendship through one of the first PRs I reviewed. SiHyun Lee and I are now both part of the triage and review team, and I’m grateful for that connection. What are your hobbies or what do you do when you’re not working? My main hobby is storytelling in a broad sense. In fact, it was a key reason I returned to programming after a long break. I enjoy discovering enduring stories from different cultures, times, and media—ranging from the deeply personal and literary to the distant and philosophical. I recently watched two Japanese classics and found I quite love them. I wrote about one of the films on my blog, and I also get to practice my Japanese, which I’ve been learning on Duolingo for about two years. I also enjoy playing speed chess. Do you have any suggestions for people who would like to start triage and review tickets and PRs? If there’s an issue you care about, or one that touches a part of the codebase you’re familiar with or curious about, jump in. Tickets aren’t always available to work on, but reviews always are, and they’re open to everyone. Reviewing helps PRs move faster, including your own if you have any open, sharpens your understanding of a component, and often clarifies the problem itself. As Simon Charette puts it: “Triaging issues and spending time understanding them is often more valuable than landing code itself as it strengthen our common understanding of the problem and allow us to build a consistent experience accross the diverse interfaces Django provides.” And you can put it on your CV! Is there anything else you’d like to say? I’m grateful to everyone who contributes to making every part of Django what it is. I’m particularly thankful to whoever nominated me to be the DSF Member of the month. I am optimistic about the future of Django. Django 6.1 is already shaping up with new features, and there are new projects like Django Bolt coming up. Happy new year 🎊! Thank you for doing the interview, Clifford and happy new year to the Django community 💚!