Django

Following the June 4, 2025 security release, the Django team is issuing releases for Django 5.2.3, Django 5.1.11, and Django 4.2.23 to complete mitigation for CVE-2025-48432: Potential log injection via unescaped request path (full description). ... [More] These follow-up releases migrate remaining response logging paths to a safer logging implementation, ensuring that all untrusted input is properly escaped before being written to logs. This update does not introduce a new CVE but strengthens the original fix. We encourage all users of Django to upgrade as soon as possible. Affected supported versions Django main Django 5.2 Django 5.1 Django 4.2 Resolution Patches to resolve the issue have been applied to Django's main, 5.2, 5.1, and 4.2 branches. The patches may be obtained from the following changesets. CVE-2025-48432: Potential log injection via unescaped request path On the main branch On the 5.2 branch On the 5.1 branch On the 4.2 branch The following releases have been issued Django 5.2.3 (download Django 5.2.3 | 5.2.3 checksums) Django 5.1.11 (download Django 5.1.11 | 5.1.11 checksums) Django 4.2.23 (download Django 4.2.23 | 4.2.23 checksums) The PGP key ID used for this release is : 3955B19851EA96EF [Less]

The Django Software Foundation is announcing a call for Django Fellow applications. A Django Fellow is a contractor, paid by the Django Software Foundation, who dedicates time to maintain the Django framework. The Fellowship program was started in ... [More] 2014 as a way to dedicate high-quality and consistent resources to the maintenance of Django. The Django Software Foundation currently supports two Fellows –Natalia Bidart and Sarah Boyce– and has approved funding for a new full-time Fellow. This position will be initially for a period of one year, but may be extended depending on fundraising levels. Beyond keeping Django running, a fellow is a representative of Django itself. They embody the welcoming culture of Django and aid the community to progress the framework. Fellows are often called upon to speak at Django conferences and events. They are also usually leading Django Sprints occurring in conferences or other setups. Hence a Django Fellow often engages in both informal and formal mentorship. Responsibilities Fellow duties include (but are not limited to): Monitoring security reports and ensuring security issues are acknowledged and responded to promptly Fixing release blockers and helping to backport fixes to these and security issues Ensure timely releases including being a release manager for a new version of Django Triaging tickets on Trac Reviewing and merging pull requests Answering contributor questions on the Forum Helping new Django contributors land patches and learn our philosophy Requirements A Django fellow reviews a very large amount of Django contributions. This requires knowledge in every aspect of web development that the Django framework touches. This turns out to be an intimidatingly-large list of technical topics, many of which are listed below. It’s not our expectation that you come into the job knowing everything on this list! We hope you’ll have solid experience in a few of these topics, particularly some of the “core” technologies important to Django (Python, relational databases, HTTP). But we fully expect that you’ll learn most of this on the job. A willingness to learn, and a demonstrated history of doing so, is more important than comprehensive knowledge. The technical topics you can expect to work on includes (and is not limited to): SQL and Databases: SQLite, MySQL, Postgres, Oracle Technical Documentation Javascript CSS Semantic HTML Accessibility UI/UX design (Web and CLI) Python async Python features (and versions), compatibility matrix, etc. Everything around HTTP Security best practices There are also: Complex processes which need adhering to Multiple discussions which need opinions and direction Requirements for both formal and informal mentorship And required professional skills such as: Conflict resolution Time management and prioritization expertise Ability to focus in short periods of time and do substantial context switches Self-awareness to recognize their own limits and reach out for help Relationship-building and coordination with Django teams, working groups, and potentially external parties. Tenacity, patience, compassion and empathy are essential Therefore a Django Fellow requires the skills and knowledge of a senior generalist engineer with extensive experience in Python and Django. Open source experience, especially in contributing to Django, is a big plus. Being a Django contributor isn't a prerequisite for this position — we can help get you up to speed. We'll consider applications from anyone with a proven history of working with either the Django community or another similar open-source community. While no geographical location is required, we have a slight preference for timezones between around -8 and +3 UTC to allow for better working hours to overlap the current fellows. If you're interested in applying for the position, please email us at [email protected] describing why you would be a good fit along with details of your relevant experience and community involvement. Lastly, please include at least one recommendation. The current hourly rate for a fellow is $82.26 USD. Applicants will be evaluated based on the following criteria: Details of Django and/or other open-source contributions Details of community support in general Understanding of the position Clarity, formality, and precision of communications Strength of recommendation(s) Applications will be open until midnight AoE, 1 July, 2025, with the expectation that the successful candidate will start around August 1, 2025. [Less]

In accordance with our security release policy, the Django team is issuing releases for Django 5.2.2, Django 5.1.10, and Django 4.2.22. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as ... [More] possible. CVE-2025-48432: Potential log injection via unescaped request path Internal HTTP response logging used request.path directly, allowing control characters (e.g. newlines or ANSI escape sequences) to be written unescaped into logs. This could enable log injection or forgery, letting attackers manipulate log appearance or structure, especially in logs processed by external systems or viewed in terminals. Although this does not directly impact Django's security model, it poses risks when logs are consumed or interpreted by other tools. To fix this, the internal django.utils.log.log_response() function now escapes all positional formatting arguments using a safe encoding. Thanks to Seokchan Yoon (https://ch4n3.kr/) for the report. This issue has severity "low" according to the Django security policy. Affected supported versions Django main Django 5.2 Django 5.1 Django 4.2 Resolution Patches to resolve the issue have been applied to Django's main, 5.2, 5.1, and 4.2 branches. The patches may be obtained from the following changesets. CVE-2025-48432: Potential log injection via unescaped request path On the main branch On the 5.2 branch On the 5.1 branch On the 4.2 branch The following releases have been issued Django 5.2.2 (download Django 5.2.2 | 5.2.2 checksums) Django 5.1.10 (download Django 5.1.10 | 5.1.10 checksums) Django 4.2.22 (download Django 4.2.22 | 4.2.22 checksums) The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E General notes regarding security reporting As always, we ask that potential security issues be reported via private email to [email protected], and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information. [Less]

In accordance with our security release policy, the Django team is issuing releases for Django 5.2.2, Django 5.1.10, and Django 4.2.22. These releases address the security issues detailed below. We encourage all users of Django to upgrade as soon as ... [More] possible. CVE-2025-48432: Potential log injection via unescaped request path Internal HTTP response logging used request.path directly, allowing control characters (e.g. newlines or ANSI escape sequences) to be written unescaped into logs. This could enable log injection or forgery, letting attackers manipulate log appearance or structure, especially in logs processed by external systems or viewed in terminals. Although this does not directly impact Django's security model, it poses risks when logs are consumed or interpreted by other tools. To fix this, the internal django.utils.log.log_response() function now escapes all positional formatting arguments using a safe encoding. Thanks to Seokchan Yoon (https://ch4n3.kr/) for the report. This issue has severity "moderate" according to the Django security policy. Affected supported versions Django main Django 5.2 Django 5.1 Django 4.2 Resolution Patches to resolve the issue have been applied to Django's main, 5.2, 5.1, and 4.2 branches. The patches may be obtained from the following changesets. CVE-2025-48432: Potential log injection via unescaped request path On the main branch On the 5.2 branch On the 5.1 branch On the 4.2 branch The following releases have been issued Django 5.2.2 (download Django 5.2.2 | 5.2.2 checksums) Django 5.1.10 (download Django 5.1.10 | 5.1.10 checksums) Django 4.2.22 (download Django 4.2.22 | 4.2.22 checksums) The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E General notes regarding security reporting As always, we ask that potential security issues be reported via private email to [email protected], and not via Django's Trac instance, nor via the Django Forum. Please see our security policies for further information. [Less]

The question was asked to the president of the DSF this year at FOSDEM, after his talk. And it is clearly a legitimate one! But… is it True? Do we actually need a 3rd party app to write an API with Django? In a lot of cases, when you require a ... [More] complex and full-featured API, I would recommend you do use one. Django REST Framework and Django Ninja being very sound choices with a bunch of nifty things you might need in a bigger project. But… what if what you need is a simple REST API that does CRUD? Do you really need a 3rd party app to do that? Let's try not to! Let's first ask what is a REST API in the context of this article. Let's limit ourselves to building this: a URL that answers to GET requests with a list of records of a single model type POST-ing to that same URL should create a new record a second URL with the primary key of a record tagged to the end. When GET-ing that URL, one should receive only that single record, in a similar format as in the list PUT-ing data to that URL should update the record and return that record with updated values DELETE-ing to that same URL should delete the record everything should be achieved using JSON Listing records from a model Chances are you have heard of generic class-based views (CBVs) in Django, the one that comes to mind when it comes to listing records is the built-in django.views.generic.ListView. ListView extends 2 other classes, BaseListView and MultipleObjectTemplateResponseMixin. Since we want to build an API, we clearly don't need to extend anything template-related. Looking at what BaseListView provides, one can notice the only thing really missing there is a render_to_response method. And this is going to be the case for most of the other base classes. This sets our starting point! The type of response we want to render is a json response and Django already provides one. So let's build a JsonViewMixin that looks like this for now: class JsonViewMixin(View): response_class = JsonResponse content_type = 'application/json' def render_to_response(self, context, **response_kwargs): response_kwargs.setdefault("content_type", self.content_type) return self.response_class(context, **response_kwargs) The next thing we have to tackle is that the context returned by BaseListView's get_context_data returns much more data than what we strictly need for this article. Also the list of records returned is not serialized to json. Serializers for mutliple formats already exist in Django core (see django.core.serializers) but I will go a different route here. There is another way to serialize data in Django that you are likely familiar with but is not labelled as clearly: forms. Forms are used in regular views to serialize models to simple types, understandable by HTML forms (mostly text) and vice-versa. This is very close to what we need, since json is also mostly text-based. To start with, using forms as serializers requires creating a new form instance for each record in the list we want to return. Let's add that to the mixin! def serialize_many(self, obj_list): return [self.serialize_one(obj) for obj in obj_list] def serialize_one(self, obj) form = self.get_form_for_object(obj) serialized = form.initial serialized['pk'] = obj.pk # forms strip pk's from their data return serialized def get_form_for_object(self, obj): form_class = self.get_form_class() kwargs = self.get_form_kwargs() kwargs['instance'] = obj return form_class(**kwargs) Why use forms? ModelForms are a built-in and robust Django tool that are built around the idea of handling the transition between Model fields and simple (and also JSON-serializable) types (mostly text and numbers). Which is exactly what we want from (de-)serializers in a lot of cases. If you need to (de-)serialize a custom field type, Django documents creating a custom form field and this covered in various places like StackOverflow. Moving on to our first View Now that we have a tool to serialize the records list returned by BaseListView let's write the first version of JsonListView. As I alluded to earlier, we need to strip down what is returned from get_context_data. class JsonListView(JsonViewMixin, BaseListView): def get_context_data(self, **kwargs): context = super().get_context_data(**kwargs) # wrapping this in a dict for security reasons return { 'results': self.serialize_many(context['object_list']) } This won't work yet because get_form_class that I used in the JsonViewMixin is only provided by classes that descend from FormMixin. Since we want this view to handle both listing and creating records, let's go and fix that in the next section! 1 down, 3 to go: Adding records First thing first, let's rebrand JsonListView and make it inherit from BaseCreateView. class JsonListCreateView(JsonViewMixin, BaseCreateView, BaseListView): Form creation and validation will be handled automatically by Django! Almost… The first concern will be with populating the form with POST data. While Django does this for you when dealing with URL encoded or multipart form data, it does not (yet) handle json-encoded POST content. But this can be handled by taking advantage of the modularity of Django's generic class-based-views and overwritting get_form_kwargs. Let's address this (in a naïve way) within the mixin as it will be applicable to any JSON view: def get_form_kwargs(self): kwargs = super().get_form_kwargs() if ( len(kwargs.get("data", {})) == 0 and self.request.content_type == "application/json" and len(self.request.body) ): # The request has a JSON body that we did not decode kwargs["data"] = json.loads(self.request.body) return kwargs An issue that could arise here is that a JSONDecoderError could be triggered. get_form_kwargs does not return a response so I don't think it is the right place to handle the exception. The post method does return a response, let's wrap the original one with a try/except (still in the mixin): def post(self, request, *args, **kwargs): try: return super().post(request, *args, **kwargs) except json.decoder.JSONDecodeError as e: return self.response_class( {"error": f"json decode error: {e.msg}"}, status=HTTPStatus.UNSUPPORTED_MEDIA_TYPE, ) Speaking of returning responses, the BaseCreateView class is built around HTML principles and its form_valid and get methods are both designed to render a form (via get_context_data). In the case of our REST API, the "create" part of things should not be involved with GET requests. Furthermore the reply to an invalid form submission should only comprise of an error (status + message) and should not require anything provided by get_context_data. Still, in regards to form validation, a valid form should not result in a redirect (behaviour of BaseCreateView) but rather in a 201 response optionally containing the representation of the created record. The form handling part is generic enough to put it in the mixin itself. The behaviour of GET is specific to the list/create view though. Let's write the code accordingly: class JsonViewMixin(View): ... def form_invalid(self, form): return self.response_class( {'errors': form.errors}, status=HTTPStatus.UNPROCESSABLE_CONTENT ) def form_valid(self, form): self.object = form.save() context = self.serialize_one(self.object) return self.response_class( context, status=HTTPStatus.CREATED ) class JsonListCreateView(JsonViewMixin, BaseCreateView, BaseListView): ... def get_context_data(self, **kwargs): # Explicitly point to BaseListView instead of `super()` # to prevent actions taken by # BaseCreateView's implementation of `get_context_data` context = BaseListView.get_context_data(self, **kwargs) return { 'results': self.serialize_many(context['object_list']) } Halfway there! That was everything needed to handle the create and list portions of our CRUD REST application. Now we can move on to the read, update, delete part. We'll do that in a second View class as it requires a slightly different URL, one that contains the pk of the resource. Both read and update functionalities are provided by Django BaseUpdateView but, as with the create/list view, the major difference in this case will be that we need a much simpler context. class JsonReadUpdateView(JsonViewMixin, BaseUpdateView): def get_context_data(self, **kwargs): return self.serialize_one(self.object) That's it!!! Well, almost… BaseUpdateView is wired to answer to POST requests for updating a record while REST good practices want us to use PUT instead. The fix for this is to raise an error in reply to POST calls while directing PUTs to the parent's post implementation. def post(self, request, *args, **kwargs): return self.response_class(status=HTTPStatus.METHOD_NOT_ALLOWED) def put(self, request, *args, **kwargs): return super().post(self, request, *args, **kwargs) One more fix… Our mixin implementation returns a 201 on form_valid. In case of any view which is not creating a record, this should be 200. Here are the necessary changes: class JsonViewMixin(View): form_valid_status = HTTPStatus.OK # new property def form_valid(self, form): self.object = form.save() context = self.serialize_one(self.object) return self.response_class( context, status=self.form_valid_status # use the new property ) ... class JsonListCreateView(JsonViewMixin, BaseCreateView, BaseListView): form_valid_status = HTTPStatus.CREATED # override in case of creation Why PUT and not PATCH? BaseUpdateView builds a form that expects all fields to be filled. Non-present fields would be reset to empty on the existing record for partial updates. I'll leave it as an exercise to the reader to override that behaviour in case of a PATCH request in order to "pre-fill the form" with existing values, maybe by using the form's initial property… 😉 Finally… The last bit of logic we have to implement is for deleting objects. Most of the code from Django's BaseDeleteView is related to creating and validating a form for confirming the user's intend on deleting the resource. This is usually not the expected behaviour for a REST API, this part being handled by whatever is calling the API. Furthermore, it doesn't implement a delete method. In the HTML world of Django's BaseDeleteView, everything is done using GET and POST. So we are (mostly) on our own for this last part. We can still leverage the get_object implementation provided by BaseUpdateView though. Here is what implementing the delete operation for our read/update/delete view looks like: class JsonReadUpdateDeleteView(JsonViewMixin, BaseUpdateView): # name changed ... def delete(self, request, *args, **kwargs): self.get_object().delete() # data is required by JsonResponse return self.response_class(data={}, status=HTTPStatus.NO_CONTENT) Conclusion This implementation is basic and clearly naïve. But it gets the job done! And this can all be done by leveraging Django-provided tools and mechanisms, mainly using Django's generic CBVs. Generic class-based views have been built in such a modular fashion that implementing one's own mini REST framework can be done in less than 100 lines of code. A non-negligible advantage of such an approach is that most libraries written to work with Django's generic CBVs are also likely to work with this implementation. This rather simple approach can certainly be improved (handling exceptions in delete… anyone?) and is clearly not going to cover everybody's use cases. And it most likely misses handling a bunch of edge cases! And if you are building a large REST API, I would say you are probably still better off using a 3rd party library but… to me, the answer to the question “Why do you need a 3rd party application to write a simple REST application with Django?” is: "You don’t" If you enjoyed this article, read more from Emma on Emma has a blog, which is where this piece was from. Or watch the FOSDEM talk that Emma reacts to: Thibaud Colas - Shifting DX expectations: keeping Django relevant 😬 | FOSDEM 2025 [Less]

We’re excited to introduce our Google Summer of Code 2025 contributors! These amazing folks will be working on impactful projects that will shape Django’s future.\ Meet the contributors 👇 A. Rafey Khan Project: Django Admin – Add Keyboard Shortcuts ... [More] & Command Palette. Mentors: Tom Carrick, Apoorv Garg Rafey will work on making Django Admin faster and more accessible through keyboard-driven workflows. Excited to see this land! Farhan Ali Raza Project: Bring django-template-partials into core. Mentor: Carlton Gibson Farhan will be enhancing Django’s template system by adding first-class support for partials—making componentized templates easier than ever.\ Saurabh K Project: Automate processes within Django’s contribution workflow. Mentor: Lily Foote Saurabh will work on streamlining how contributors interact with Django repo—automating repetitive tasks and improving dev experience for all. \ A huge shoutout to our mentors (and Org Admin Bhuvnesh Sharma) and the broader Django community for supporting these contributors! 💚\ \ Let’s make this a summer of learning, building, and collaboration. [Less]

We’re excited to introduce our Google Summer of Code 2025 contributors! These amazing folks will be working on impactful projects that will shape Django’s future. Meet the contributors 👇 A. Rafey Khan Project: Django Admin – Add Keyboard Shortcuts ... [More] & Command Palette. Mentors: Tom Carrick, Apoorv Garg Rafey will work on making Django Admin faster and more accessible through keyboard-driven workflows. Excited to see this land! Farhan Ali Raza Project: Bring django-template-partials into core. Mentor: Carlton Gibson Farhan will be enhancing Django’s template system by adding first-class support for partials—making componentized templates easier than ever. Saurabh K Project: Automate processes within Django’s contribution workflow. Mentor: Lily Foote Saurabh will work on streamlining how contributors interact with Django repo—automating repetitive tasks and improving dev experience for all. A huge shoutout to our mentors and the broader Django community for supporting these contributors! 💚 Let’s make this a summer of learning, building, and collaboration. [Less]

Happy Global Accessibility Awareness Day! We thought this would be a fitting occasion to announce our brand new Django accessibility statement 🎉 Did you know that according to the WebAIM Million survey, 94.6% of sites have easily-detectable ... [More] accessibility issues? We all need to work together to build a more inclusive web (also check out our diversity statement if you haven’t already!). There are accessibility gaps in Django itself too. This statement improves transparency, and clearly states our intentions. And we hope it encourages our community and the industry at large to more widely consider accessibility. How to use this statement Read it, share it with your friends, or in a procurement context! Use it to understand where there are gaps in Django that need to be addressed on projects. And opportunities to contribute to Django and related projects ❤️ Factor it into legal compliance. For example with the European Accessibility Act. Starting June 2025, accessibility becomes a legal requirement for large swaths of the private sector in the European Union. Share it with venues for Django events to demonstrate the importance of accessibility for their competitiveness. How you can help Take a moment to provide any feedback you might have about the statement on the Django Forum. Let us know if you would prefer additional reporting like an ATAG audit, or VPAT, ACR, or any other acronym. Let us know if you’d like to contribute to the accessibility of the Django community! 🫶 [Less]

Credit: DjangoCon Europe 2025 organizers We had a blast at DjangoCon Europe 2025, and hope you did too! Events like this are essential for our community, delighting both first-timers and seasoned Djangonauts with insights, good vibes, and ... [More] all-around inspiration. This year’s conference brought together brilliant minds from all corners of the globe. And featured early celebrations of Django’s 20th birthday! ⭐️🎂🎉 After launching in 2005, Django turns 20 in 2025, and the conference was a great occasion for our community to celebrate this. And work on the sustainability of the project together. We need more code reviews Our Django Fellow Sarah Boyce kicked off the conference with a call for more contributions – of the reviewing kind. In her words, Django needs your help. Every day, contributors submit pull requests and update existing PRs, but there aren't enough reviewers to keep up. Learn why Django needs more reviewers and how you can help get changes merged into core. We need more fundraising Our Vice President Sarah Abderemane got on stage to encourage more financial support of Django from attendees, showcasing how simple it is to donate to the project (get your boss to do it!). We have ambitious plans for 2025, which will require us to grow the Foundation’s budget accordingly. Annual meeting of DSF Members Our Board members Tom Carrick, Thibaud Colas, Sarah Abderemane, and Paolo Melchiorre were at the conference to organize a meeting of Members of the Django Software Foundation. This was a good occasion to discuss long-standing topics, and issues of the moment, such as: Diversity, equity and inclusion. Did you know we recently got awarded the CHAOSS DEI bronze badge? We need to keep the momentum in this area. Management of the Membership at the Foundation. With different visions on how much the membership is a recognition or a commitment (or both). There was interest in particular in sharing more calls to action with members. Content of the website. A long-standing area for improvement (which we’re working on!) All in all this was a good opportunity for further transparency, and to find people who might be interested in contributing to those areas of our work in the future. Birthday celebrations There was a cake (well, three!). Candles to blow out. And all-around great vibes and smiles, with people taking pictures and enjoying specially-made Django stickers! Up next We have a lot more events coming up this year where the Foundation will be present, and bringing celebrations of Django’s 20th birthday! PyCon US 2025 It’s on, now! And we’re present, with a booth. Come say hi! There will be Django stickers available: PyCon Italia 2025 Some of the PyCon Italia team was there at DjangoCon Europe to hype up their event – and we’ll definitely be there in Bologna! They promised better coffee 👀, and this will have to be independently verified. Check out their Djangonauts at PyCon Italia event. EuroPython 2025 We got to meet up with some of the EuroPython crew at DjangoCon Europe too, and we’ll definitely be there at the conference too, as one of their EuroPython community partners 💚. There may well be birthday cake there too, get your tickets! Django events And if you haven’t already, be sure to check out our next flagship Django events! DjangoCon Africa 2025 Aug. 11, 2025 | Arusha, Tanzania 🇹🇿 DjangoDay India Sept. 7, 2025 (tentative) | Bangalore, India 🇮🇳 DjangoCon US 2025 Sept. 8, 2025 | Chicago, Illinois, USA 🇺🇸 Thank you to everyone who joined us at DjangoCon Europe, and thank you to the team behind the conference in particular ❤️. DjangoCon Europe continues to show the strength and warmth of our community, proving that the best part of Django is truly the people. See you at the next one! PS: if you’re in Europe and like organizing big events, do reach out to talk about organizing a DjangoCon Europe in your locale in the coming years. [Less]

Credit: DjangoCon Europe 2025 organizers We had a blast at DjangoCon Europe 2025, and hope you did too! Events like this are essential for our community, delighting both first-timers and seasoned Djangonauts with insights, good vibes, and ... [More] all-around inspiration. This year’s conference brought together brilliant minds from all corners of the globe. And featured early celebrations of Django’s 20th birthday! ⭐️🎂🎉 After launching in 2005, Django turns 20 in 2025, and the conference was a great occasion for our community to celebrate this. And work on the sustainability of the project together. We need more code reviews Our Django Fellow Sarah Boyce kicked off the conference with a call for more contributions – of the reviewing kind. In her words, Django needs your help. Every day, contributors submit pull requests and update existing PRs, but there aren't enough reviewers to keep up. Learn why Django needs more reviewers and how you can help get changes merged into core. We need more fundraising Our Vice President Sarah Abderemane got on stage to encourage more financial support of Django from attendees, showcasing how simple it is to donate to the project (get your boss to do it!). We have ambitious plans for 2025, which will require us to grow the Foundation’s budget accordingly. Annual meeting of DSF Members Our Board members Tom Carrick, Thibaud Colas, Sarah Abderemane, and Paolo Melchiorre were at the conference to organize a meeting of Members of the Django Software Foundation. This was a good occasion to discuss long-standing topics, and issues of the moment, such as: Diversity, equity and inclusion. Did you know we recently got awarded the CHAOSS DEI bronze badge? We need to keep the momentum in this area. Management of the Membership at the Foundation. With different visions on how much the membership is a recognition or a commitment (or both). There was interest in particular in sharing more calls to action with members. Content of the website. A long-standing area for improvement (which we’re working on!) All in all this was a good opportunity for further transparency, and to find people who might be interested in contributing to those areas of our work in the future. Birthday celebrations There was a cake (well, three!). Candles to blow out. And all-around great vibes and smiles, with people taking pictures and enjoying specially-made Django stickers! Up next We have a lot more events coming up this year where the Foundation will be present, and bringing celebrations of Django’s 20th birthday! PyCon US 2025 It’s on, now! And we’re present, with a booth. Come say hi! There will be Django stickers available: PyCon Italia 2025 Some of the PyCon Italia team was there at DjangoCon Europe to hype up their event – and we’ll definitely be there in Bologna! They promised better coffee 👀, and this will have to be independently verified. Check out their Djangonauts at PyCon Italia event. EuroPython 2025 We got to meet up with some of the EuroPython crew at DjangoCon Europe too, and we’ll definitely be there at the conference too, as one of their EuroPython community partners 💚. There may well be birthday cake there too, get your tickets! Django events And if you haven’t already, be sure to check out our next flagship Django events! DjangoCon Africa 2025 Aug. 11, 2025 | Arusha, Tanzania 🇹🇿 DjangoDay India Nov. 2, 2025 (tentative) | Bangalore, India 🇮🇳 DjangoCon US 2025 Sept. 8, 2025 | Chicago, Illinois, USA 🇺🇸 Thank you to everyone who joined us at DjangoCon Europe, and thank you to the team behind the conference in particular ❤️. DjangoCon Europe continues to show the strength and warmth of our community, proving that the best part of Django is truly the people. See you at the next one! PS: if you’re in Europe and like organizing big events, do reach out to talk about organizing a DjangoCon Europe in your locale in the coming years. [Less]