In 2010 I was again a mentor in the Google Summer of Code program for the TYPO3 Association. A week ago I attended the Mentor Summit of this year's program. It was the culmination of GSoC 2010 and as expected a very cool event. :)
Everyone who has been at Google will probably agree that it is a hell of a place to be. From a beach volleyball field and free-to-use bikes over a cafeteria equipped with lighting and sound equiment worth thousands of dollars to cool offices with micro-kitchens and Lego-equipped relaxation areas, it has a lot to offer. But, location aside, this has also been...
My first real unconference
I knew the concept, but seeing is believing. After about an hour a schedule spanning 12 rooms each having 9 slots over two days was done. Amazing, albeit chaotic and crowded group effort.
Ingo Renner (also from the TYPO3 project) and me handed in two sessions, one being the (by now traditional) CMS meetup and the other a session on a mixture of quality assurance, continous integration and build systems.
I'll try to summarize what I gathered from those and other sessions.
After having attended a session on static code analysis where I felt a little lonely (everyone seemed to to use some variant of C or Java), in the CMS corner we are back in PHP country.
Around the table sat people from Drupal, Wordpress, Geeklog, Midgard, MoinMoin, Sakai, ATutor, MediaWiki, Pier and of course TYPO3. It was a friendly discussion (yes, we usually don't hit each other when we meet) and it turned out current topics are similar across projects. Hot topics where (again) Git and semantic technologies, but we touched PHP version requirements, release cycles, unit testing and MSIE 6 support (everyone wants to get rid of it, some cannot, though). CMIS was being discussed and I brought JSOP into the discussion. Quite a few had heard about the Aloha editor, and Henri Bergius (whom I remember from back in my Midgard days) is even part of some EU-funded project that is involving it.
There was some feeling of agreement around the table that supporting common standards for content exchange and semantics would provide benefit for all our projects (far more important than what we use for storage in the background, another topic we touched). Let's see where we stand a year from now.
Continuous Integration and QA
This was a session I suggested and I started off by giving an overview of what we have done so far in the FLOW3 and TYPO3 Phoenix projects: introduced Git, Gerrit, Hudson for running tests and code metrics; put up easy but strict coding guidelines; instill a firm belief in quality in all team members.
That led to a general discussion on the usefulness of tests (effort vs. results) and the special problems you have in some cases (like in the blender project, where they need to render and compare images in tests).
Git is Hot, Gerrit runner up
Whether it was the session on "war stories" from Git migrations or the one on continuous integration, the question of Git came up regularly. A lot of projects (it feels like all, to be honest) are switching to Git at the moment and those who did switch do not want to go back.
I could tell about our recent experiences with the move of FLOW3 and TYPO3 Phoenix to Git and Gerrit, and had nothing bad to tell. In fact Gerrit caused most people to show enthusiasm for code review right away.
I had hoped to have a chat with Shawn Pearce (the Gerrit maintainer) and was lucky that he attended the summit. We had a nice chat about (mostly Gerrit and Git) things, he's as nice as he comes across on the mailing list.
A field where semantics have been in use more widespread in the past is online learning. The Sakai project is one of the more fundamental projects in that area, backed by various universities in the US. Carl Hall, one of the Sakai developers, and I talked about content interchange a little. The next Sakai version will be focusing on content reuse a lot, moving the tool away from being the central container towards being the place where content is aggregated (anything RESTful can serve up stuff) and enriched, only to be again available for other systems (and of course users) to consume.
That gave me a warm fuzzy feeling inside, since we had just implemented a first part of our RESTful content access in TYPO3 Phoenix during sprint 4, which allows you to access not only pages but also content itself in a fine-grained yet easy way. Seems like a perfect match, I'll try to keep in touch with Carl to see how we can integrate TYPO3 and Sakai in the future.
A very nice session was dealing with introducing agile methodologies into projects. There was not much new to learn for me, but the session was one of the most productive and produced really nice notes - probably because the folks there were used to making meetings productive. :)
Some tools were pointed out (Pivotal tracker, Kunagi, Redmine Backlogs) and we agreed on the importance of having someone with guts is needed to drive acceptance, especially with management, in most cases.
It turned out that we are doing rather well with our implementation of Scrum in the TYPO3 Phoenix project. Our adjustments to cope with the distributed team, diverse working environments and other obstacles were agreed on at large.
A session of which I caught only some part was revolving around maintaining documentation, getting users involved in that and some tooling around all that.
A major issue with documentation are actually issues with the documentation: bugs, outdated parts, unclear passages. An issue tracker for this is an option, as well as the use of a wiki (those can become messy pretty fast if you don't watch out). An impressive example for directly editable (read: fixable) documentation can be found in the Boost documentation. The system sends the changes to the maintainer for review and thus combines wiki-like ease of use with stricter control.
The problems of keeping screenshots and screencasts up to date were discussed, automation and keeping focused on one thing at a time solve some of that. Other areas in documentation that are even harder than writing the original content is keeping translations in sync and creating useful indexes (something you don't really need for digital versions - but in printed docs it is vital!).
With all the buzz around continuous integration, Hudson build farms and automated deployment you sooner or later run into the need for setting up yet another server. And it better be quick and painless. That's why we looked into Puppet recently, and it turns out they have friendly folks at that project as well. I talked to Matt Robinson and he pointed out some plans they have (involving Marionette Collective) and urged me to give feedback, as they are eager to improve things in the future - sounds good to me!
Some of the conversation of course had more of a personal value. I learned some facts about Plan 9 (from Bell Labs, not the movie) through Erik Quanstrom and was recommended some nice pieces of interactive fiction by ... someone who at the same time could explain the reason for Perl's existence and some background on Haskell to me.
The fact that Java was deprecated by Apple on OS X also caused some rumblings, and the fun fact is that now Java developers (at least on the Mac) now are in a similar situation as PHP developers: both run on a platform that has no real company backup... ;)
Around the world exists a lot of awesome chocolate, and Robert Kaye organized a huge amount of it to appear at the summit. There was a session on motivation and chocolate, but even afterwards enough chocolate was left to be spread out over three tables for everyone to taste. Next year will probably have more chocolate, as everyone should bring some... Yum!
Last but not least: Carol is magic (we have proof of that).