I started contributing to Django core after a failure in our project.

I had to rename a model attribute without touching our database. The solution was simple.

# Simple attribute to rename.
author = models.ForeignKey('Author')

# 1. Add db_column param.
author = models.ForeignKey('Author', db_column='author')

# 2. Change the attribute name.
creator = models.ForeignKey('Author', db_column='author')

It was really obvious to me that it should be a noop to database. Even Stack Overflow had a response confirming that.

The first migration locked our database because it dropped and recreated a constraint.

SET CONSTRAINTS "core_book_author_id_eaa1580d_fk_core_author_id" IMMEDIATE;
ALTER TABLE "core_book" DROP CONSTRAINT "core_book_author_id_eaa1580d_fk_core_author_id";
ALTER TABLE "core_book" ADD CONSTRAINT "core_book_author_id_eaa1580d_fk_core_author_id"
    FOREIGN KEY ("author_id") REFERENCES "core_author" ("id") DEFERRABLE INITIALLY DEFERRED;

Sad day, but right after that I prepared to run the second step. That time I checked the generated SQL with sqlmigrate command and discovered it will do the same thing again.

To avoid another failure, I did only a SeparateDatabaseAndState change. Works great, but Django could do better handling these migrations.

from django.db import migrations, models

class Migration(migrations.Migration):
    atomic = False
    dependencies = [
        ('core', '0137_auto_20200227_1304'),
    ]
    operations = [
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.RenameField(
                    model_name='book', old_name='author', new_name='creator',
                ),
            ],
            database_operations=[],
        ),
    ]

After that, I checked Django tickets and didn't found anything related. Created a ticket and implemented two pull requests to fix both steps: AlterField with db_column addition should be a noop and RenameField with db_column should be a noop. They were merged and released with Django 3.1.1 after long PR conversations.

Django is a huge codebase and even a minor change like that took me some days, changing the wrong things in the different wrong ways. I learned a lot and was able to fix another migrations issue: AlterOrderWithRespectTo() with ForeignKey crash when _order is included in Index().

Right after these fixes, I upgraded our Django and hit a recent regression: App with default_app_config and without apps.py or with an empty apps.py crashes.. It was a quick fix, but lots of tests written.

When our new intern started exploring Django querysets, he had an issue with queryset in_bulk operation, because of incomplete docs and it generated a new ticket and quick fix: Queryset in_bulk docs don't explicit field_name as kwarg only.