House conventions for writing code in a Django codebase: formatter and linter compliance (black, isort, djlint, flake8), imports at module top with real refactors for circular imports, docstrings over comment blocks, maintained libraries over hand-rolled code, full test coverage as a merge gate, one squashed migration…
Working practices for git itself and the forge around it, independent of what the repository contains. Creating a repository with the settings it should have had from day one: asking private or public first, because on GitHub Free a private repository cannot have rulesets or branch protection at all, then squash-only…