Russell Keith-Magee: No! Bad! Pony! or explaining Django’s development process¶

Tags: django, djangocon

Russell was the first one to use the term pony. It describes a certain kind of feature request. There are lots of requests and we can’t satisfy everyone. “You can’t have your pony”. Calling such a request a “pony” means “yes, we know a pony is nice, but you’ll have to wait for it and you might not get it in the end”.

He gave this talk earlier (9 months ago or so) and had to dig up quite some new examples as Django 1.2 actually granted a lot of ponies. We actually do work :-)

Some requests are bad ponies. They might come back from time to time. In any case, they keep on getting rejected by the core team. Some reasons:

• It is just plain wrong. We cannot defy gravity. We will not go against certain standards. Or an API is proposed that everyone is bound to get wrong (see Rusty Russell’s interface levels). Or it violates DRY (don’t repeat yourself).

• Plain impractical. It solves a problem that doesn’t exist: YAGNI. Architecture astronauting. Or you only address a small part of something way bigger. And we’re not going to re-implement the entire emailing system because of a small edge case: you just might have to code up something yourself.

• Not a good fit for django’s design. Some solutions are fine in itself, but they do not fit Django. Django is opinionated. For instance, sqlalchemy is a fine ORM, but django’s core developers like Django’s ORM which was purpose-build for Django’s use cases. Same with Jinja: fine templating language, but we like Django’s more. Same with the test framework (like replacing it with Nose). Consistency is a good thing and it is partially because of those theoretically-replacable existing components.

  Ignoring the philosophy is also adding AJAX out of the box to forms: Django is a server side framework and it does not want to dictate the client side.

  “Just add a setting” also goes against Django’s design. Every new setting means a user has another setting to understand. And a setting is a deferred decision. We will add settings now and then, but we try to avoid it.

• Takes the project in a wrong direction. Feature creep, for instance. Django is a web framework, not a web server: so don’t make the django development server multithreaded or so, that’s what a web server is for. Django is also not going to offer connection pooling: there’s existing external software for that.

  Adding something to the core means the core team needs to worry about it from now on. And the core team has limited resources! More lines of code also automatically means more bugs.

  Same with adding something to contrib. Adding something mostly means that something’s developer gets added to the core team. But the basic core problems stay: more code, more maintenance needs.

  What is django.contrib, actually? A collection of optional, de facto standard implementations of common patterns. And: if you have one good implementation, there should be no need of making a second one. There’s one session implementation and that’s the only one that’s needed. But django-tagging? There are several implementations already…

• Comes without an offer of assistance. “You should write more blogs”. “You should have precompiled PDF documentation”. All these things can be done just fine by people outside of the core, so core developers will by default say “no” to them.

  Also: massive features that someone wants the core team to do for them. Schema evolution, for instance.

Comment on patches: don’t just dump a patch in the issue tracker and complain half a year later that the patch hasn’t been applied. Work with the core devs on the django-dev mailinglist to get the patch looked at and vetted. And improve the patch continually.

Open source is strange. There’s no vendor. Russell promises to refund every single dollar people spend on buying Django if they’re not satisfied :-) So clamoring for a fix won’t work. Offer to help out. Do unglamorous tasks, like reviewing tickets and answering questions on django-users. Get your name known, it helps with getting your tickets and patches looked at quicker.

Build karma by making good patches. Include documentation and tests. Also make small patches and fixes over time so that the core devs start to trust you and your patches.

You need to be an advocate for your wishes. An advocate that is trusted is

Out of necessity, some apparently rude measures are needed to get work done. Ignoring people is the only way Russell actually gets things done. There are 15k people on django-users! The core team has limited resources, so we need to make the best use of that time.

And that’s where trust comes in: someone you trust is someone you listen to much sooner. So build trust.

If you must fix something: do research. Demonstrate that you understand the problem. Look at the history. Write code that demonstrates that your approach is workable.

Russell doesn’t want days-long energy sapping negative threads on the django dev mailinglist, he wants to have discussion to make Django better.

Also: see everything in perspective. You not getting your pony isn’t the end of the world. Loads of people use Django, so Django of itself isn’t totally broken. You might have a problem, so work to get it fixed. Or find out how to work around your problem.

In the end, Django is doing most things fundamentally OK. We’re open for improvement suggestions, of course. But also for that: work with us instead of against us.

Question: what to do if your ticket is marked “duplicate” or “wontfix”? It sounds a bit rude and I don’t know what to do afterwards. Answer: known problem. We’re currently trying to add a sort of form letter when marking tickets in that way. That’ll tell you what you can do and what the short word “duplicate” really means to tell you.

Answer to a different question: polite reminders are fine. “I’ve uploaded a fresh patch last week, could you take a second look?”. Something like “Why didn’t any of you lazy bastards look at my ticket” won’t help. Reminding is fine; politeness is key.

Question on reviewing tickets when you don’t think you have the experience. Answer: make it easy for the one with the necessary experience to make the call. Make a small test that demonstrates the problem, for instance. Often the ticket is a piece of text instead of a specific technical piece of code. Or do some background research and post the results.