Having your pony and committing it too - Jacob Burch¶

Tags: django, djangocon

Jacob Burch hopes you can learn from him if you’re new at contributing to open source. He won’t cover virtualenv, git, django’s core code structure. And also not what to get involved in. What’s this talk about? About you if you have something you want (“a pony”) to get into Django core.

You are initially probably going to be a bit afraid. Jacob showed a couple of quotes about people that were initially not quite sure/certain when committing to Django. Then he showed the names of the people those quotes came from: they’re now all core committers :-)

Two balances you have to keep in mind:

• You should be both pro-active and patient. This is a tough balance to strike. If you manage it, it helps a lot.

• You should be both confident and humble. Be humble, but be convinced of your idea. How to help here? The best thing is to run all the tests. It will give you confidence that your solution works (if it does). And it’ll make you humble once you realize all the end cases that Django (and thus your fix) needs to support.

There are three broad categories of contributions:

Bug fixes

Start with a test condition. Something works or it doesn’t. A test that demonstrates an issue is worth 20 emails.

Major contributions

Do your homework. Search trac, search the django developer mailinglist, become familiar with the code you’re proposing to change. You need a go-ahead beforehand, so discuss it on the mailinglist.

Minor additions

Treat it as a major contribution. Only a beforehand go-ahead isn’t needed here.

(Jacob did some live coding, trying to get a push into Django. In the meantime, he continued with the presentation by showing himself on video :-) )

Some do’s/dont’s when mailing about something:

• Don’t communicate entitlement. Don’t focus only on your own needs.

• Communicate patience. Accept that this is the start of a conversation.

• State the problem clearly.

• Show confidence: propose a clear solution. This really helps the core devs, as they have a clear proposal to work from instead of having to come up with something themselves. Creative energy is expensive energy.

• Show your homework. Ticket numbers, list potential downsides/drawbacks.

• Show humility. If you’re unsure of an aspect, just ask.

Code is important, but most of the effort will probably be spend in discussing it. That said, here are some code related suggestions:

• PEP8, unless it is consistently ignored on a certain point. Stay consistent locally.

• Respect existing style.

• Comments are your friend. Don’t comment too heavily, but make sure that anything unusual is explained.

• Get some peer review before submitting.

Repeat to yourself: you are not your code. Your ego is not on the line. Separate yourself from your code. Humility is really important. Your patch might not get accepted. You might get negative feedback. Don’t take it personally. Your code is not yourself, even though it might feel like your own baby.

If it is not getting reviewed: remember that core devs are busy and might not have had time to review it. A bit of persistence is important, but don’t irritate people. Tip: get to know people that can commit on conferences or at sprints. That helps.

Once you do get feedback: iterate quickly and get back quickly on the feedback, otherwise the core dev has to load everything back into their head.