Planet Python

Last update: April 20, 2026 01:44 AM UTC

April 19, 2026

Django Weblog

DSF member of the month - Rob Hudson

For April 2026, we welcome Rob Hudson as our DSF member of the month! ⭐

Rob Hudson's profile, with bamboos behind him. He wear glasses and slightly smiling in front the camera.

Rob is the creator of django-debug-toolbar (DDT), tool used by more than 100 000 folks in the world. He introduces Content-Security-Policy (CSP) support in Django and contribute to many open source packages. He has been a DSF member since February 2024.

You can learn more about Rob by visiting Rob's website and his GitHub Profile.

Let’s spend some time getting to know Rob better!

Can you tell us a little about yourself

I'm a backend Python engineer based in Oregon, USA. I studied biochemistry in college, where software was just a curiosity and hobby on the side, but I'm grateful that my curiosity turned into a career in tech. My earliest memory of that curiosity was taking apart my Speak & Spell as a kid to see how it worked and never quite getting it back together again.

How did you start using Django?

I followed the path of the "P"s: Perl, then PHP, then Python. When Ruby on Rails arrived it was getting a lot of attention, but I was already enjoying Python, so when Django was announced I was immediately drawn to it. I started building small apps on my own, then eventually led a broader tech stack modernization at work, a health education company where we were building database-driven learning experiences with quizzes and a choose-your-own-adventure flow through health content. Django, Git, and GitHub all came together around that same time as part of that transition. Fun fact: my GitHub user ID is 1106.

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 building a few projects with FastAPI lately and have really come to appreciate the type-based approach to validation via Pydantic. The way typing syntax influences the validation logic is something I'd love to see influence Django more over time.

Erlang has a feature called the crash dump: when something goes wrong, the runtime writes out the full state of every process to a file you can open and inspect after the fact. As someone who built a debug toolbar because I wanted to see what was going on under the hood. Being provided a freeze frame of the exact moment things went wrong, full state intact, ready to inspect sounds like magic.

The Rust-based tooling emerging in the Python ecosystem is fascinating to watch. Tools like uv, ruff, and efforts around template engines, JSON encoders, ASGI servers, etc. The potential for significant speed improvements without losing what makes Django Django is an interesting space.

What projects are you working on now?

I have a couple of personal fintech projects I'm playing with, one using FastAPI and one using Django. I've been enjoying exploring and wiring up django-bolt for the Django project. I'm impressed with the speed and developer friendliness.

On the django-debug-toolbar front, I recently contributed a cache storage backend and have a longer term idea to add an API layer and a TUI interface that I'd love to get back to working on someday.

Which Django libraries are your favorite (core or 3rd party)?

Django Debug Toolbar (I may be slightly biased). Beyond that: whitenoise and dj-database-url are great examples of libraries that do one thing well and get out of your way. I'd also add granian, a Rust-based ASGI server. And django-allauth, which I'm somehow only just trying for the first time. For settings management I've cycled through a few libraries over the years and am currently eyeing pydantic-settings for a 12-factor approach to configuration.

What are the top three things in Django that you like?

The community. I've been part of it for a long time and it has a quality that's hard to put into words. It feels close knit, genuinely welcoming to newcomers, and there's a rising tide lifts all boats mentality that I don't think you find everywhere. People care about helping each other succeed. The sprints and hallway track at DjangoCon have been a wonderful extension of that.

The ORM. Coming from writing a lot of raw SQL, I appreciate the syntax of Django's ORM which hits a sweet spot of simplicity and power for most use cases.

Stability, documentation, and the batteries included philosophy. I appreciate a framework that at its core doesn't chase trends, has a predictable release cycle, amazingly well written docs (which makes sense coming from its journalism background), and there's enough built in to get surprisingly far without reaching for third party packages.

The inspiration came from Symfony, a PHP framework that had a debug toolbar built in. At the time, I was evaluating frameworks for a tech stack transition at work and thought, why doesn't Django have one of these? So I started hacking on a simple middleware that collected basic stats and SQL queries and injected the toolbar HTML into the rendered page. The first commit was August 2008.

The SQL piece was personally important. Coming from PHP where I wrote a lot of raw SQL by hand, I wanted to see what the ORM was actually generating.

The nudge to actually release it came at the first DjangoCon in 2008 at Google's headquarters. Cal Henderson gave a keynote called "Why I Hate Django" and showed a screenshot of Pownce's debug toolbar in the page header, then talked about internal tooling at Flickr similar to what the Django debug toolbar has currently. Seeing those motivated me to tweet out what I was working on that same day. Apparently I wasn't the only one who wanted to see what the ORM was doing.

It has been created in 2008, what are your reflections on it after so many years?

Mostly gratitude. I had a young family at the time and life got busy, so I stepped back from active maintenance earlier than I would have liked. Watching it flourish under the maintainers who stepped up has been really wonderful to see. They've improved it, kept up with releases, supported the community, and have done a better job of it than I was in a position to do at the time, so I'm grateful to all who carried the torch.

At this point I contribute to it like any other project, which might sound strange for something I created, but it's grown bigger than my early involvement and that feels right. I still follow along and it makes me happy to see it continuing to grow and evolve.

What I didn't anticipate was what it gave back. It helped launch my career as a Django backend developer and I'm fairly certain it played a role in landing me a job at Mozilla. All from of a middleware I hacked together just to see what the ORM was doing.

Being a maintainer is not always easy despite the fact it can be really amazing. Do you have any advice for current and future maintainers in open source?

For what it's worth, what worked for me was building things for fun and to learn rather than setting out to build something popular. I also didn't worry too much about perfection or polish early on.

If life gets busy or your interests move on, I'd say trust the community. Have fun, and if it stops being fun, find some enthusiastic people who still think it's fun and hand it to them gracefully. That worked out better than I could have hoped in my case.

I'm genuinely curious about how AI changes open source. If simple utilities can be generated on the fly rather than installed as packages, what does that mean for small focused libraries? My hope is that the value of open source was never just the code anyway. The collaboration, the issue discussions, the relationships. AI can generate code but it can't replicate those things.

One thing I've noticed is newer developers using AI to generate patches they don't fully understand and submitting them as contributions. I get the impulse, but I'd encourage using AI as a tool for curiosity rather than a shortcut. Let it suggest a fix, then dig into why it works, ask it questions, iterate, which is something I often do myself.

You have introduced CSP support in Django core, congratulations and thank you for this addition! How did the process of creating this contribution go for you?

I picked up django-csp at Mozilla because it had become unmaintained and was a blocker from upgrading to newer Python and Django versions. What started as a simple maintenance task turned into a bit of a yak shave, but a good one. Getting up to speed on CSP led to ticket triage, which led to a refactor, which eventually led me to a 14 year old Django issue requesting CSP in core. Once the refactor was done I made the mistake of actually reading that 14 year old ticket and then felt personally responsible for it.

The more I worked in the space the clearer the ecosystem problem became. As a third party package, django-csp couldn't provide a standardized API that other packages could reliably depend on. If a third party library needed to add nonces to their own templates, they couldn't assume django-csp was installed. Seeing that friction play out in projects like debug toolbar and Wagtail convinced me that CSP support made sense in core.

Working with the Django fellows through the process was a genuine pleasure and I have enormous respect for what they do. They are patient, kind, and shaped what landed in core immensely. What surprised me most was how much they handle behind the scenes and how gracefully they manage the constant demands on their attention. Huge props to Natalia in particular for guiding a large and complex feature through to completion.

Do you remember your first contribution to open source?

Before Django I'd been tinkering on the web for years. I built tastybrew, an online homebrew recipe calculator and sharing site, partly to scratch my own itch and partly to get deeper with PHP and hosting my own projects. Back then open source collaboration wasn't what it is today. Before GitHub there was Freshmeat, SourceForge, emailed patches, maybe your own server with a tarball to download.

My first Django contribution was a small fix to the password reset view in 2006. Over the next several years there were around 40 or so contributions like docs corrections, admin improvements, email handling, security fixes. Contributing felt natural because the code was open and the community was welcoming.

I joined Mozilla in 2011 and shifted focus for a while. Mozilla was quietly contributing quite a bit back to the Django ecosystem during those years, with many 3rd party Django libraries, like django-csp. One of my favorite open source contributions was when I collaborated with a colleague on a Python DSL for Elasticsearch that eventually became the basis for Elastic's official Python client.

What are your hobbies or what do you do when you’re not working?

Reading, cooking, and getting outside when I can. I try to eat a whole food plant based diet and enjoy cooking in that style. Not sure it counts as a hobby but I enjoy wandering grocery stores, browsing what's new, reading ingredients, curious about flavors, thinking about what I could recreate at home.

Getting away from screens is important to me. Gardening, hiking, camping, long walks, travel when possible. Petrichor after rain. Puzzles while listening to audiobooks or podcasts. I brew oolong tea every day, a quiet ritual where the only notification is my tea timer.

Code has always felt more like curiosity than work to me, so I'm not sure where hobby ends and the rest begins.

If you have a Django codebase that needs some love, I'm available for contract work. I genuinely enjoy the unglamorous stuff: upgrading legacy codebases, adding CSP support, and refactoring for simplicity and long term maintainability. There's something satisfying about stepping back, seeing the bigger picture, and leaving things cleaner than you found them. You can find me on GitHub at robhudson.

Doing this interview was a nice way to reflect on my career. I can see that curiosity and adaptation have been pretty good companions. I'm grateful Django and its community have been a big part of that journey.

Thank you for doing the interview, Rob !

April 19, 2026 04:28 PM UTC

April 18, 2026

EuroPython

Humans of EuroPython: Nikoś (nikoshell)

EuroPython wouldn&apost exist without our dedicated volunteers who work tirelessly behind the scenes. They design our website, set up the call for proposals system, review hundreds of submissions, carefully select talks, coordinate speakers, and handle countless logistical details. Every aspect of the conference reflects their passion and expertise.

April 18, 2026 05:00 PM UTC

Seth Michael Larson

More thoughts on Nintendo Switch 2 storage prices

April 18, 2026 12:00 AM UTC

April 17, 2026

Mike Driscoll

Textual – An Intro to DOM Queries (Part I)

In this article, you will learn how to query the DOM in Textual. You will discover that the DOM keeps track of all the widgets in your application. By running queries against the DOM, you can find widgets quickly and update them, too. You will be learning the following topics related to the DOM: The […]

The post Textual – An Intro to DOM Queries (Part I) appeared first on Mouse Vs Python.

April 17, 2026 12:57 PM UTC

Real Python

The Real Python Podcast – Episode #291: Reassessing the LLM Landscape & Summoning Ghosts

What are the current techniques being employed to improve the performance of LLM-based systems? How is the industry shifting from post-training towards context engineering and multi-agent orchestration? This week on the show, Jodie Burchell, data scientist and Python Advocacy Team Lead at JetBrains, returns to discuss the current AI coding landscape.

April 17, 2026 12:00 PM UTC

Quiz: Working With Python Virtual Environments

Test your knowledge of Python virtual environments, from creating and activating them to installing packages with pip.

April 17, 2026 12:00 PM UTC

April 16, 2026

Talk Python to Me

#545: OWASP Top 10 (2025 List) for Python Devs

The OWASP Top 10 just got a fresh update, and there are some big changes: supply chain attacks, exceptional condition handling, and more. Tanya Janca is back on Talk Python to walk us through every single one of them. And we're not just talking theory, we're going to turn Claude Code loose on a real open source project and see what it finds. Let's do it.

April 16, 2026 08:24 PM UTC

Django Weblog

New Technical Governance - request for community feedback

Hello Django community,

The Steering Council is excited to share our proposed new technical governance and ask for your feedback. Last year we suspended the formal voting process of the Steering Council. The updates we’re proposing would bring how we’ve been operating into alignment with the written governance.

From the motivation section:

This is a revisitation of Django's technical governance in which a simplification and reduction was made to make it more approachable to more people. The goals of these changes are the following:

Make it easier to enact our governance.

Make it easier for others to understand our governance.

Make the governance more flexible, allowing more action with less procedure.

You can read DEP 0019 here.

Adoption plan

The goal is to have this governance accepted and in place by 2026-07-01. Our timeline is as follows, but may change depending on feedback.

2026-04-16: Announce new technical governance, solicit feedback
2026-05-07: Merge in minor feedback changes
2026-05-28: Resolve major feedback concerns
2026-06-11: Steering Council and DSF Board vote on and approve DEP

What we need from you

We would like to know if we are achieving our goals with this document. For example, do you feel that this makes our governance easier to understand, do you feel like you have a better understanding of who is eligible to run for the Steering Council, is it clear how Django operates from a process perspective?

Beyond that, if you have other feedback around the changes, please share it. This has gone through a high degree of review from the Steering Council and Board over the past 5 months, but that doesn’t mean there aren't areas where it can be improved.

Anyone can participate in this process on the Forum thread here.

April 16, 2026 07:59 PM UTC

PyCharm & Django annual fundraiser

For another year, we are thrilled to partner with our friends at JetBrains on the annual "Buy PyCharm, Support Django" campaign. This is the first of two fundraisers we're running with JetBrains this year, and it's one of the most impactful ways the community can support the Django Software Foundation.

"JetBrains is a cornerstone in the Django community, consistently helping us understand our evolving landscape. Their annual survey provides invaluable insights into the community's needs, trends, and tools, ensuring we stay on the pulse of what matters most."

Jeff Triplett, President, Django Software Foundation

Your support of this campaign helps fund key initiatives such as:

Django Fellows: Ensuring the rapid development and maintenance of Django.
Djangonaut Space: Onboarding new contributors to the Django project.
Django Girls: Making the Django community accessible to programming beginners around the world.
International events and conferences: Supporting DjangoCons, one-day events, meetups, and other community gatherings around the world.

How the campaign works

From today to May 1, when you purchase PyCharm at a 30% discount through our special campaign link, JetBrains will donate an equal amount to the Django Software Foundation. You get a professional IDE that's trusted by Django developers worldwide, and the DSF receives a matched contribution.

Get 30% off PyCharm, Support Django

Thank you, JetBrains

Beyond this campaign, JetBrains contributes to the Django ecosystem in ways that are easy to overlook but hard to overstate. Their Django Developers Survey, State of Django report, and broader Python Developers Survey give the entire community a clearer picture of where Django and Python are heading each year.

"JetBrains is one of our most generous fundraising partners year after year, helping us sustain and grow the Django ecosystem. We deeply appreciate their commitment, leadership, and collaboration."

Thank you to JetBrains for another year of partnership, and thank you to everyone who participates in this campaign. Together, we can ensure the continued success and growth of the framework we all rely on.

Other ways to donate

If you would like to donate in another way, especially if you are already a PyCharm customer, here are other ways to donate to the DSF:

On our website via credit card
Via GitHub Sponsors
Benevity Workplace Giving Program - If your employer participates, you can make donations to the DSF via payroll deduction.
For those able to make a larger donation as corporate sponsors ($2000+), check out our corporate sponsors form

April 16, 2026 05:45 PM UTC

Python Software Foundation

Announcing Python Software Foundation Fellow Members for Q4 2025! 🎉

April 16, 2026 02:45 PM UTC

Real Python

Quiz: Welcome to Real Python!

Get a tour of Real Python, find resources for your skill level, and learn how to use the community to study effectively.

April 16, 2026 12:00 PM UTC

Learning Path: Python Game Development

Build Python games from command-line projects to 2D graphical games with turtle, Tkinter, Pygame, and Arcade.

April 16, 2026 12:00 PM UTC

death and gravity

Learn Python object-oriented programming with Raymond Hettinger

Even if you haven't heard of Raymond Hettinger, you've definitely used his work, bangers such as sorted(), collections, and many others. His talks had a huge impact on my development as a software engineer, are some of the best I've heard, and are the reason *you should not be afraid of inheritance* anymore.

April 16, 2026 09:00 AM UTC

Bruno Ponne / Coding The Past

Exploring the MET API with Python - Francisco Goya's Artworks

The act of painting is about one heart telling another heart where he found salvation.

— Francisco Goya

Francisco Goya is one of my favorite artists. His work has a beautiful darkness that tells a lot about his experience in his time. In this post, we’ll dive into his world using the Metropolitan Museum of Art (MET) application programming interface (API), which gives developers access to data on hundreds of thousands of artworks.

You will learn how to interact with the MET API using Python. We will journey through the process of making HTTP requests, parsing the returned JSON data into a structured pandas DataFrame, and exploring the collection to extract meaningful insights about Goya’s work.

1. Requesting data from the API

We begin by importing the requests library, which allows us to send HTTP requests to the MET REST API in Python. We’ll query the search endpoint to find Goya’s paintings. In API terms, an endpoint is a specific URL used to access a particular resource.

The MET API has four endpoints starting with “https://collectionapi.metmuseum.org/”:

GET /public/collection/v1/objects returns a listing of all valid objectID available to use.
GET /public/collection/v1/objects/[objectID] returns a record for an object, containing all open access data about that object, including its image (if the image is available under Open Access).
GET /public/collection/v1/departments returns a listing of all departments of the museum.
GET /public/collection/v1/search returns a listing of all objectID for objects that match the search query.

You can find more details about each endpoint and its functionality in the official MET API documentation.

tips_and_updates

A REST (Representational State Transfer) API is a set of rules used to communicate between your computer and the MET server using HTTP methods and endpoints. Note that many APIs require authentication; however, the MET API is public and does not require an API key.

content_copy Copy

import requests
import pandas as pd

search_query = "https://collectionapi.metmuseum.org/public/collection/v1/search?hasImages=true&q=Francisco Goya"

response = requests.get(search_query)
search_data = response.json()

print(f"Found {search_data['total']} artworks for Francisco Goya.")

API endpoints can be followed by query parameters that refine our search. In the example above, hasImages=true filters for objects with images, and q specifies our search term—in this case, the artist’s name.

The requests library contains a method called get(), which we use to send our request to the API, passing our endpoint saved in the string search_query.

The resulting response object can then be parsed into a JSON structure using the .json() method.

2. Converting JSON to a list of painting ids

While JSON is the standard for data exchange, working with raw JSON can be cumbersome for direct data analysis. In Python, you can think of JSON as a dictionary of keys and values. These values can themselves be other dictionaries, lists, numbers, strings, or booleans. By printing the search_data object, we can see that it’s a dictionary containing two main keys:

total: An integer representing the total number of objects returned.
objectIDs: A list containing the unique IDs of the artworks matching our search.

To retrieve the list of IDs associated with the key “objectIDs” we use the standard dictionary notation search_data["objectIDs"] and save it to the variable goya_ids.

content_copy Copy

print(search_data)
goya_ids = search_data["objectIDs"]

3. Getting the details of each of Goya’s works

To retrieve details for each artwork — such as its title, date, and thematic tags — we need to iterate through the list of IDs and send a request to the /objects/{objectID} endpoint for each item. We implement this using a for loop that repeats the request for each artwork.

(Note: Depending on the number of results, fetching these details can take a few minutes. We use time.sleep(1) to respect the API’s rate limits and avoid being blocked.)

content_copy Copy

import time

all_objects_data = []


for object_id in goya_ids:
    try:
        obj_response = requests.get(f"https://collectionapi.metmuseum.org/public/collection/v1/objects/{object_id}")
        obj_response.raise_for_status() 
        all_objects_data.append(obj_response.json())
    except requests.exceptions.RequestException as e:
        print(f"Error for object ID {object_id}: {e}")
    
    time.sleep(1) # Respect the API, one request per second to be safe

# Convert the gathered data to a DataFrame
goya_df = pd.json_normalize(all_objects_data)

# Filter only Goya works
goya_df = goya_df[goya_df['artistDisplayName'].str.contains('Goya', na=False)]

We use a try-except block to ensure the loop continues even if a specific object ID fails to load. We also log any errors to help with debugging.

Finally, we convert the collected data into a Pandas DataFrame using pd.json_normalize. Since a broad search might return works about Goya or mentioning him in metadata, we filter the DataFrame to ensure the artistDisplayName actually contains “Goya.”

The resulting DataFrame contains intriguing data about each of his works, including name, year when the painting or drawing was started and finished, descriptive tags and dimensions, among other information. Feel free to explore it. We will continue working with the descriptive tags in the next steps.

4. Flattening nested JSON data

For keys whose values are lists or other dictionaries, the resulting columns will contain those respective objects. This happens, for example, with the tags column. When you have nested elements like this, you can “flatten” them into a tabular format.

JSON data structure

Flattening an element changes the granularity of the data. Whereas before each row represented a single artwork, in the flattened table each row represents an individual tag belonging to one artwork.

To flatten these nested tags, we can use json_normalize by specifying the element to unnest in the record_path. We also include the objectID in the meta parameter so we don’t lose the relationship between a tag and its original artwork. Later on, we can join this tags table back to our main DataFrame if we want.

content_copy Copy

tags_df = pd.json_normalize(
    all_objects_data,
    record_path='tags',
    meta=['objectID']
)

5. Visualizing the most frequent themes

The MET API provides a tags field containing descriptive terms associated with each artwork. To understand the prevailing themes in Goya’s works — famous for documenting the social upheaval and dark realities of his era — we can extract these terms and calculate their frequency.

Once we isolate the individual tags into a new column, we can use matplotlib to create a horizontal bar plot of the top 10 terms and check if indeed his artwork contained themes related to death and misery.

content_copy Copy

import matplotlib.pyplot as plt

# Calculate the frequency of each term for the filtered Goya artworks
# We filter tags_df to only include IDs present in our filtered goya_df
term_frequency = tags_df[tags_df['objectID'].isin(goya_df['objectID'])]['term'].value_counts().reset_index()
term_frequency.columns = ['term', 'count']

# Select the top N terms for better readability if there are many unique terms
# For this example, let's take the top 10 terms
top_terms = term_frequency.head(10).sort_values(by='count', ascending=True)

plt.figure(figsize=(12, 8))
plt.barh(top_terms['term'], top_terms['count'], color='#FF6885')

plt.title('Top 10 Most Frequent Terms in Goya Dataset', fontsize=20)
plt.xlabel('Frequency', fontsize=16)
plt.ylabel('Term', fontsize=16)
plt.xticks(fontsize=14)
plt.yticks(fontsize=14)
plt.tight_layout()
plt.show()

Top 10 Most Frequent Terms in Goya Dataset

Top 10 Most Frequent Terms chart

The resulting visualization provides a fascinating window into Goya’s thematic world. Beyond common subjects like “Men,” “Women,” and “Portraits,” we see a strong representation of “Bulls” (reflecting his famous Tauromaquia series) and “Self-portraits.”

Most strikingly, terms like “Death” and “Suffering” appear prominently in the top 10. This data-driven insight confirms Goya’s historical reputation as an artist who didn’t shy away from the darker aspects of the human experience. By quantifying these themes through the MET API, we move from subjective observation to empirical evidence of his artistic focus.

Plate 43 from "Los Caprichos": The sleep of reason produces monsters (El sueño de la razon produce monstruos)

You could also use the main dataset we created to collect a series of images of Goya works. I am thinking of using AI to help me download all images of Goya in the public domain and try to build a model to describe or classify them in Python. Feel free to use the data and let me know about your analysis. Leave your comments or any questions below and happy coding!

Conclusions

The requests library combined with pd.json_normalize makes extracting and structuring data from web APIs both seamless and efficient.
Navigating public collections like the MET API enables us to perform large-scale data analysis on historical and cultural artifacts.
Combining data extraction with clear visualizations (using Matplotlib) provides interpretable insights into an artist’s thematic legacy and creative focus.

April 16, 2026 12:00 AM UTC

April 15, 2026

Django Weblog

Django Has Adopted Contributor Covenant 3

We’re excited to announce that Django has officially adopted Contributor Covenant 3 as our new Code of Conduct! This milestone represents the completion of a careful, community-driven process that began earlier this year.

What We’ve Accomplished

Back in February, we announced our plan to adopt Contributor Covenant 3 through a transparent, multi-step process. Today, we’re proud to share that we’ve completed all three steps:

Step 1 (Completed February 2026): Established a community-driven process for proposing and reviewing changes to our Code of Conduct.

Step 2 (Completed March 2026): Updated our Enforcement Manual, Reporting Guidelines, and FAQs to align with Contributor Covenant 3 and incorporate lessons learned from our working group’s experience.

Step 3 (Completed April 2026): Adopted the Contributor Covenant 3 with Django-specific enhancements.

Why Contributor Covenant 3?

Contributor Covenant 3 represents a significant evolution in community standards, incorporating years of experience from communities around the world. The new version:

Centers impact over intent, recognizing that even unintentional harm requires accountability and repair
Emphasizes consent and boundaries, making explicit that community members must respect stated boundaries immediately
Addresses modern harassment patterns like sea-lioning, coordinated harassment, and microaggressions
Includes clearer guidance on enforcement, transparency, and accountability

By adopting this widely-used standard, Django joins a global community of projects committed to fostering welcoming, inclusive spaces for everyone.

What’s New in Django’s Code of Conduct

While we’ve adopted Contributor Covenant 3 as our foundation, we’ve also made Django-specific enhancements:

In-person event guidance: Added requirements and best practices for Code of Conduct points of contact at Django events
Affiliated programs documentation: Clarified scope and expectations for programs that reference Django’s Code of Conduct
Bad-faith reporting provisions: Added protections against misuse of the reporting process
Escalation processes: Established clear procedures for handling disagreements between working groups
Enhanced transparency: Updated our statistics and reporting to provide better visibility into how we enforce our Code of Conduct

You can view the complete changelog of changes at our Code of Conduct repository.

Community-Driven Process

This adoption represents months of collaborative work. The Code of Conduct Working Group reviewed community feedback, consulted with the DSF Board, and incorporated insights from our enforcement experience. Each step was completed through pull requests that were open for community review and discussion.

We’re grateful to everyone who participated in this process—whether by opening issues, commenting on pull requests, joining forum discussions, or simply taking the time to review and understand the changes.

Where to Find Everything

All of our Code of Conduct documentation is available on both djangoproject.com and our GitHub repository:

Code of Conduct: djangoproject.com/conduct
Reporting Guidelines: djangoproject.com/conduct/reporting
Enforcement Manual: djangoproject.com/conduct/enforcement-manual
FAQs: djangoproject.com/conduct/faq
GitHub Repository: github.com/django/code-of-conduct

How You Can Continue to Help

The Code of Conduct is a living document that will continue to evolve with our community’s needs:

Propose changes: Anyone can open an issue to suggest improvements
Join discussions: Participate in community conversations on the Django forum, Discord, or DSF Slack
Report violations: If you experience or witness a Code of Conduct violation, please report it to conduct@djangoproject.com
Stay informed: Watch the Code of Conduct repository for updates

Thank You

Creating a truly welcoming and inclusive community is ongoing work that requires participation from all of us. Thank you for being part of Django’s community and for your commitment to making it a safe, respectful space where everyone can contribute and thrive.

If you have questions about the new Code of Conduct or our processes, please don’t hesitate to reach out to the Code of Conduct Working Group at conduct@djangoproject.com.

Posted by Dan Ryan on behalf of the Django Code of Conduct Working Group

April 15, 2026 08:49 PM UTC