December 21 is Volunteer Responsibility Amnesty Day, one of two days every year that allows you to build out your responsibility inventory and decide what you have time for.

Volunteer Responsibility Amnesty Day is about checking with yourself, and ending the commitments you need to end – maybe by taking a break, or by rotating it on to someone else, or by sunsetting a project.

It’s one of the best ideas in tech because it creates space to de-commit from projects we might not otherwise have time for, but we feel like we’d be letting people down by stepping back from. It’s a wonderful excuse to step back from projects that have been weighing on your mind.

What I’m stepping down from

This year, I decided it was time to step down from the Paramiko, Fabric, and Invoke Triage Teams because I had not been active there in years. I volunteered to help triage issues that were always a bit over my head.

I joined when Jeff Forcier needed some extra hands, and it might have helped get another maintainer signed up who could help out more. At PyCon US this year, I got to hang out with Jeff. I gave him a heads-up that I felt like I was excess baggage to the project because my good intentions were no longer turning into helping out the project. I have much respect for Jeff (#teamjeff) and all three of these projects.

If you have free cycles and can help with these projects, please check out the open issues and see if you can help. I use all three beneficial projects in one way or another every week.

What you can do

Suppose you are signing up for projects but are not fulfilling your commitment. In that case, I encourage you to use Volunteer Responsibility Amnesty Day as motivation to step down from whatever project or responsibility you may have.

I also want to call out some members of the Python and Django communities. If you are signing up to help with projects you know you won’t have time for, please step back and encourage someone else to help with those projects and roles. If you know that famous face you see plastered on every website and they are friends, please ask them if they know about Volunteer Responsibility Amnesty Day and share your list. That nudge may help them decide if they are taking on too much.

Last week, I wrote but didn’t publish some notes about why the Django and Python communities use so many Google Forms.

The simple answer is that Google Forms are quick and easy to set up, and data can be easily exported via Google Sheets or a CSV file.

Getting data in and out of Django isn’t hard, but why isn’t it as easy as using Google Forms?

I’d love to see a Django version of Google Forms that we can all use.

Has anyone solved this problem?

From a technical perspective, Django ships with a JSONField, which can store any form data we want without having to migrate databases. Turning a flat JSONField into CSV is already a solved problem.

Please note: I am not looking for a Django forms wrapper or your opinions about why Django should use your fancy Django forms tool.

One of the biggest mysteries in Django is why I have to run django-admin from my terminal instead of just running django. Confusingly, django-admin has nothing to do with Django’s admin app.

If you have ever wondered why and wanted to type django from your terminal, my new project, django-cli-no-admin solves this problem for you.

I looked at several package names on PyPI, including django-cli, which I liked the best (someone is name squatting this package.)

I gave up and went with django-cli-no-admin for lack of a better name.

# new school
uv pip install django-cli-no-admin

# old school
pip install django-cli-no-admin

# to use it...
django --version 

This tool aliases Django’s django-admin script does but we shorted the name by 50%:

[project.scripts]
django = "django.core.management:execute_from_command_line"

Should Django adopt this?

Yes. But we can leave django-admin alone since we have ~20 years of history referencing it.

How long has this lived in your head?

Almost two decades.

Where is the code?

https://github.com/jefftriplett/django-cli-no-admin

Friends, I’m launching a half-finished website idea that I have been playing around with for a while. djangotv.com is focused on promoting and searching Django videos to make discovery easier.

I wanted to launch DjangoTV before I left DjangoCon US 2024, so I’m technically announcing it from the airport. Last year, I launched Django News Jobs during the Django sprints because I was annoyed by the state of the various Django job boards.

After a year of hearing people complain about Django and Python YouTube videos not getting enough views, I decided to address the problem by building out a website to help organize and promote them.

DjangoTV is not competing with pyvideo.org. PyVideo is a fantastic resource for the Python community, and one of my goals is to make it easier to get Django content on PyVideo, too.

DjangoTV is incomplete, and I have many ideas to improve it, including backfilling some of our older conferences, adding presenters, and adding some other metadata to make it a useful community resource.

I focused on DjangoCon videos to bootstrap the project, and we’ll slowly expand our archives. I have been extracting good quotes, adding transcriptions, and adding better summaries. Please expect this to change a lot. I even launched the website with DEBUG turned on for a few days before I turned it off.

Your feedback is crucial to us. If you have any ideas or suggestions, please don’t hesitate to share them.

Most importantly, names change, people change, and bodies change. It’s essential to me that we respect each other and handle this with care. If you have a concern or need us to pull a video, please don’t hesitate to reach out; we will take care of it.

I know people outside the US 🙄 at this, but please stop releasing major security updates and backward incompatible changes over major US, international, and religious holidays.

Given that major security updates are embargoed and scheduled weeks and months in advance, it’s essential to coordinate and avoid conflicts. A simple check of the calendar before scheduling announcements can prevent such issues.

Even if you give everyone two weeks' notice, aka what GitHub just did, wait to schedule them for release over a holiday weekend.

Historically, the Python and Django communities have also been guilty of this, so I’m not just finger-pointing at GitHub. We can all do better here.

Update: 100% unrelated to this: Django security releases issued: 5.1.1, 5.0.9, and 4.2.16. Thank you, Natalia (and Sarah) for scheduling this after the US is back from a major holiday.

Renaming a table in Django seems more complex than it is. Last week, a client asked me how much pain it might be to rename a Django model from Party to Customer. We already used the model’s verbose_name, so it has been referencing the new name for months.

Renaming the model should be as easy as renaming the model while updating any foreign key and many-to-many field references in other models and then running Django’s make migrations sub-command to see where we are at.

The main issue with this approach is that Django will attempt to create a new table first, update model references, and then drop the old table.

Unfortunately, Django will either fail mid-way through this migration and roll the changes back or even worse, it may complete the migration only for you to discover that your new table is empty.

Deleting data is not what we want to happen.

As it turns out, Django supports a RenameModel migration option, but it did not prompt me to ask if we wanted to rename Party to Customer.

I am also more example-driven, and the Django docs don’t have an example of how to use RenameModel. Thankfully, this migration operation is about as straightforward as one can imagine: class RenameModel(old_model_name, new_model_name)

I re-used the existing migration file that Django created for me. I dropped the CreateModel and DeleteModel operations, added a RenameField operation, and kept the RenameField operations which resulted in the following migration:

from django.db import migrations


class Migration(migrations.Migration):

    dependencies = [
        ('resources', '0002_alter_party_in_the_usa'),
    ]

    operations = [
        migrations.RenameModel('Party', 'Customer'),
        migrations.RenameField('Customer', 'party_number', 'customer_number'),
        migrations.RenameField('AnotherModel', 'party', 'customer'),
    ]

The story’s moral is that you should always check and verify that your Django migrations will perform as you expect before running them in production. Thankfully, we did, even though glossing over them is easy.

I also encourage you to dive deep into the areas of the Django docs where there aren’t examples. Many areas of the docs may need examples or even more expanded docs, and they are easy to gloss over or get intimidated by.

You don’t have to be afraid to create and update your migrations by hand. After all, Django migrations are Python code designed to give you a jumpstart. You can and should modify the code to meet your needs. Migration Operations have a clean API once you dig below the surface and understand what options you have to work with.