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.
- 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.