Sprint introduction and closing (djangocon.eu)

Tags: djangocon, django, nelenschuurmans

Closing off djangocon!

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.

blog comments powered by Disqus
 
vanrees.org logo

About me

My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):