How is Django developed?

How to contribute?

Learn by example

Triage stage

Unreviewed | Accepted | Ready for checkin
| Design Decision Needed | Someday/Maybe
| Fixed on a branch

Severity

Normal | Release blocker

Flags

☑ Has patch
☐ Needs documentation
☐ Needs tests
☐ Patch needs improvement

Type

Uncategorized | Bug | New feature | Cleanup/optimization

Component

contrib.admin | ... | Database layer (models, ORM) | ...

Version

SVN | 1.4 | 1.4-rc2 | 1.4-rc1 | 1.3.1 | ...

Flags

☑ Easy pickings
☑ UI/UX

Source: https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#triage-workflow

Mailing-lists

• django-developers
• django-i18n
• django-updates
• django-users

IRC channels

• #django-dev
• #django

Conferences and events

All this — and much more — is explained in the docs!

Contributing to Django

Help other developers

• Answer questions on django-users and #django
• Share what you learn on your blog

Extend the ecosystem

• Contribute to open source Django projects
• Release your own code as reusable apps, package them and upload them to PyPI

Aim for high quality

• Enforce coding standards
• Write good documentation

Report bugs

Everyone knows how to report a bug, right?

Triage tickets

Reduce the "Unreviewed tickets" count.

Write patches

With tests and docs. Or improve existing patches.

Review patches

Reduce the "Patches needing review" count.

Reference repository

$ svn checkout \
    https://code.djangoproject.com/svn/django/trunk

Official mirrors

$ git clone https://github.com/django/django.git
$ hg clone https://bitbucket.org/django/django

Pull requests must be referenced in a Trac ticket!

Creating a patch

$ svn di > $TICKETID.patch     # in the trunk dir
$ git diff > $TICKETID.patch

Applying a patch

$ wget https://code.djangoproject.com/attachment/\
  ticket/$TICKETID/$TICKETID.patch
$ patch -p0 < $TICKETID.patch  # -p1 for a git/hg diff
$ git apply $TICKETID.patch

If you're really serious, install djpatch.py:

$ djpatch.py $TICKETID

Less code

• Promote third-party apps
• Deprecate some contrib apps
• Remove debatable features

Thorough implementations

"If we do it in Django, let's do it right."

Test everything

"There aren't any tests" isn't an excuse :)

#17674

Patch

#17319

Patch 1

Patch 2

Patch 3

#17675

Patch 1

Patch 2

#3100

patch 1

...

patch 7

#2626

proposal

Interesting things

• How are people going to use this feature?
• What is the right level of abstraction?
• What is going to break, and how badly?
• How am I going to convince the core team?

1. I'm not in your brain help me understand your problem quickly
2. Written communication is hard don't be too smart
3. Most people try to help only sometimes they fail
4. Most code is written for a reason not always a good one
5. Auto-fix is auto-break given a different set of expectations
6. A known bug is bad a broken fix is worse