Core developers panel (djangocon.eu)¶

Tags: djangocon, django

Participants: Andrew Godwin, Idan Gazit, Russell Keith-Magee, Alex Gaynor, Jannis Leidel.

(Note: I didn’t get the first 15 minutes of the panel: there was a free chair massage downstairs. I was in line for half an hour, so I didn’t want to skip it).

You’ve added core contributors last year. How has that played out? Positive experience? Well, it worked out real well. The people we added should have been added a long time ago. There’s been a complete absense of a committer bottleneck, great. There’ve been a few hickups, but we really should have done it much earlier. They’re planning on adding a couple of extra committers soonish.

“Several people have said that they have used (or considered using) non-Django solutions for all or part of their stack for realtime/async performance (eg “the node.js crisis”). Do you think this is a crisis that Django needs to address? If so how? Not too big a problem. There are solutions, like gunicorn with eventlet. Sometimes, however, django can get in the way but there’s lots of room and opportunity for improvement. Another good solution came up earlier this conference with the mozilla add-on website: django for most of the site and something else for the one single big-hitter endpoint. And, see Martijn Faassen’s zope talk, there’s room for cleaning up django’s internal dependencies to make it easier to swap things out and other things in.

What needs to go into core? Translated content, there are some solutions and perhaps a common one could be integrated into core. Something piston-like. Some south-like migration tool.

A harder one: perhaps we should lower the server-side-only barrier that django has: become less client-agnostic. That last one is hard as we’ve tried very hard to be client-agnostic. Idan thinks server-side-only is good, though, as it gives you lots of choices on the client side. Well, in any case it is something django will have to watch.

What’s the best way to drive new features into core? Well, we need the community. We are a community. So we are a collection of human beings. So basic sociology applies. So build trust. So interact. Don’t demand Attention Now. Time is limited. Make it easy to help you. Make sure we get to know you as someone it is good to invest scarce time in. What also helps: get small things out of the way so that the core team can move more quickly. And definitively don’t put any things IN the way.

When can we expect the awesome new design from Idan for that admin? Wife, family, job. He plans to work on it in his spare time this summer. And he plans on working with other projects’ UX teams. And… he hopes to have something visible by djangocon US. Idan wants to have more designers on board, btw, so volunteers are welcome.

Are you looking at sponsorship for django? Corporate money? The django foundation is trying to be a bit more active regarding sponsors. But beforehand they need to have a bit more clear what they actually want to do with the money. By djangocon US they hope to have something. Regarding helping: financing sprint locations and sprints, for instance. Alternatives are available. Russell, for instance, is being sponsored by a company to attend all djangocons. Or give back as a company by organizing a conference.

Sprints: also the python software foundation sponsors sprints. So if you have one, get in contact.

The admin: could it become a realtime app?. We could perhaps move it outside of the core to make it easier to customize and fork. A realtime version could be feasible. Idan wants a non-realtime version with all functionality first. And perhaps django should be more about the basic “protocol” so that new things can be plugged in: a protocol for plugging in new functionality into the django debug toolbar or into the admin for instance.