Paul Bissex proposed, organized, hosted, and MC’d a Django unconference (Django.June) over the weekend. Paul has a wrapup on his blog and Jay Graves put some flickr pictures up. There were over 20 people in attendance, and by all accounts it was a huge success. I was only able to catch the second half, and was not able to stay for the music festival. It was fantastic seeing people whom I primarily know from reading mailing lists, blogs, and irc chats. There were so many things I wanted to talk to specific people about that never happened. The conversations were just too interesting. Adrian’s impromptu talk on contributing to Django, the development process and his experiences on contributing to large OSS projects was illuminating. I almost didn’t go out to feed the meter because of it; there was a two hour max, and the car next to me got ticketed.

One point he made really hit home. The documentation of a project has the largest impact on it’s public/blog perception. There is a perception that Django does not integrate with AJAX or is not ‘AJAX Ready‘. I’m not sure what those terms really mean (as many people have different opinions) but the real reason people are uncertain about django+ajax is that there is a lack of documentation on using javascript toolkits with it. Large parts of the ‘fullstack’ vs. ‘bag of pieces’ Django/TurboGears flamewars (at least thats what it degraded into) was largely due to people viewing the documentation of both frameworks as being the full story. Adrian mentioned that he now views projects differently and that if a feature is not mentioned in the documentation, he his first reaction is to now dig deeper as the implementers may have solved the problem but not had time to properly document it.

The ‘project’ system in the Django Tutorial is a source of problems. I was happy to hear that Adrian does not use projects or the manage.py tool. These have been stumbling blocks for making portable Django code, and were a late addition to django; added as part of open sourcing the project. He implied they were meant to add some initial structure and a framework for the framework. The end result is people view the project system as what the django framework is. The end result is people learning django are being taught how to make their code not portable. Some improvements to the tutorial and the notes for application developers will help. currently there is a huge wealth of information in the wiki, but it is not cross linked with the main documentation, so some things are hard to find.

Another thing that Adrian mentioned was how friendly the Django community and the dev team in particular are. This is an understatement. The python community, in general, is an exceptionally polite, welcoming, and friendly group. The Django subculture is at the far right of that bell curve. The members of the Django IRC channel and mailing lists deserve the majority of the credit for making the PyCon-Tech software viable. Almost all the solutions to problems came from them, not me (the SQL outer join query extensions for view history for instance). It was actually fun to solve the problems because I got to work on them with a bunch of cool people, even if it was in a very irregular, hands off, pastebin fashion. I wanted to talk more the conference software with David Schein (who helped write it), but we kept going off on tangents (or at least I did).

Well thats enough for tonight. I think I covered about 10min of the 4 hours I was there. It was a very information dense and rewarding day.

I hope this becomes a yearly event. My plans for next year already include getting a hotel room and the entire family going up for the day.