How things work in the Zeitgeist team.

Lately I have been reflecting on the past 2 years (Zeitgeist will turn 2 years on the 10.10.10 with the release of Unity). I would love to talk about the geeky aspect of what we are doing, but decided to put our development process as well as community management in the spotlight for once.

Although some people consider me the team lead, I have to disappoint you. I am not. I did write the first lines of code but none of that is there anymore. There is no such thing as a lead on the Zeitgeist side. I delegate some issues here and there and I would describe myself more as the person with the overview about what is happening in the Zeitgeist universe but not the lead. Why that? Because:

  • Technically I lack some skills compared to the Zeitgeist hackers.
  • I can not force a feature or code into trunk.
  • I don't get to take decisions in the name of the project.
And its not that bad. It does have its drawbacks, but for the sake of the project it is the best that could happen. Here are some random small examples of things we do and why we think its good that way.
  • We all get along and the fact that we recognize each others strengths allows us to delegate tasks very efficiently. This reflects a lot on the review process where branches get be merged. It allows us to associate tasks and issues with the person most fit to work on them. Knowing one is admired for a specific skill create the feeling of "belonging to the project" and appreciation.
  • Bug fixing even if its one line of code has to be confirmed by another peer in the Zeitgeist team. No one pushes into trunk unless some other Zeitgeist member takes a look. Some people say this slows development, we say it is a sign of QA
  • New features have to be voted for democratically (no such thing as veto). When a feature can not make it into trunk, there is a transparent reasoning and vote to back it up. This way there is no hard feelings within the team. It also keeps us on track of not expanding into new use cases but rather be perfect at what we want to deliver. Also with every new feature a heck lot of new bugs come in.
  • Every release has someone else managing it, due to non Zeitgeist obligations. This reduces the burn out effect as well as keeps each one in the team aware of other aspects of the project that he does not really work on constantly.
  • Having a handful of main contacts for a project is always good, given that those contacts talk and discuss matters on a daily or bi-daily basis. It allows us to distribute community matters amongst us.
  • We "Hack & Hype". So when you write code or have an idea you should write a post. This allows the community to know what we are working on and opens up opportunities for new developers to jump in.
I will get more into the "Hack & Hype" concept that the Zeitgeist team embraces with my next post. There are much more things I would like to write about. The Zeitgeist team for me is by far the most fun team I got to work with and each one effected the way things work here on our side. Yet that deserves an article of its own. So I will leave you with a list of people who are not actively involved in Zeitgeist but influenced the way things happen on our side: Thank you all, and I hope this third year of Zeitgeist will be better than ever.