Sprint introduction and closing (djangocon.eu)¶

Sprinting intro¶

Starting at 10:00, we’ll sprint for two days. A show of hands showed that many people were first-timers at a sprint. Great!

The goal of a sprint is to get some serious amount of work done by being in one location with everyone present and available. Focused work. Collaborative work.

Prerequisites:

• Read the django contribution docs beforehand. It helps you to get a good feel for the process.

• Get a working django setup.

Where are we? We’re working in the early phase of the 1.4 release. That goes into trunk. New features can still get in.

Beginners:

• Report a bug. A good bug report is something that can be easily checked or verified. Good information.

• Triage bugs. Look at existing bugs and see if they’re valid. Try to reproduce.

• Test whether available patches apply cleanly to trunk. Report back on the bug. Perhaps you can fix the patch yourself? Also try and check whether the actual problem is solved or whether some duct tape is taped over.

• Test a branch/feature. Play around with it.

Intermediate. You have used django for a long time, perhaps? Been at previous sprints?

• Write a patch yourself.

• Eat some dogfood. Several things have been fixed, but need to be applied to the rest of django. Remove the last couple of absolute URLs from the admin, for instance.

• Write documentation. Solve the “more tutorials coming soon” line that has been in the docs for a long time. Oh, the newer you are, the better you’re suited to writing tutorials!

• Write tests.

Advanced:

• Work on big-ticket items.

• Kick around a big design idea. Anything on the gsoc-suggestion list is good to work on.

• Propose something controversial. Get a feel to see if anyone is interested

Now, what to work on? Basically pick an area that interests you!

About patches: generate them relative to svn trunk. They will need tests. “But testing is hard” is not an option. Especially areas that aren’t currently tested need tests. So: every patch needs tests.

Tests mean unit tests, not doctests. This was a recent change. Test as close to the problem as possible (so proper unit testing, not functional testing if possible). And try to integrate with existing fixtures.

Patches also… need to be documented. Especially everything that smells remotely like a new feature. Don’t worry about spelling: that’ll get reviewed and fixed. The first draft gets us from nothing to something we can work on.

Good to work on regarding documentation: either tutorials or extending the class-based views docs. Those last ones are barely adequate.

If in doubt: ask!

And: have fun!

Closing¶

Lots of thank-you’s. I even got a bottle of booze for my blogging. Much appreciated.

Some personal comments¶

Very smooth and well-run conference. The wifi worked the whole time, for instance. Everything started and stopped on time. The food was good. Enough coffee/milk/icetea. Snacks. Good location. Friendly atmosphere. Remco Wendt steered everything in a friendly way.

And I wrote down a lot of things to check out later. Ideas for speed improvements. Ideas for apps to use. Ideas for server setups. Best-practice ideas that I should implement at our company. Great.

Advertisement for my company¶

It feels good that the company where I work, Nelen & Schuurmans, sponsored this conference. See the image below.

We’re hiring, btw. Django work in a civil engineering and ecological setting (water consultancy). Just browse my blog to get an idea, for instance by looking at these tagged posts: http://reinout.vanrees.org/weblog/tags/nelenschuurmans.html .