Edited: I would like to prefix this whole discussion that I am very happy with the effort that people are putting into things like the release team, without which we would never get anywhere in 4.0. They, like the oxygen artists, and many other elements of KDE get beat up on the dot, and elsewhere for perceived problems without remembering to recognize the very valuable work they are doing. This entry is supposed to be about how to improve it in the future for those few small details that could be improved, and is not reflecting on the release team as a whole, merely on some organizational structures. By sebas' comments, I think I've given the wrong impression, and I can assure that my main intention is only to help refine this process for future releases, not to slag on the team. I will yield to his idea that this is probably the wrong time for this discussion which should wait for a few more months.
I would retract this entry at this point if it weren't for the fact that there are already comments which would look funny without the entry. So instead, I get to see how many fontsets and web rendering engines make the strike tag look silly.
Cheers folks, and happy hacking.
I do agree that the project has grown up to the point where having a single release-dude is unmanageable - I sure as hell wouldn't like to be that single point of failure and I'm certain that most of the current members of the release team wouldn't either, however that doesn't mean that the current pseudo-anarchy of the release-team is the best and most effective.
You see, in psychology there is a concept known as the "diffusion of responsibility". It works as follows: if only two people are on a bus and one has a heart attack, the other person is extremely likely to try to help; whereas if the bus is crowded, people will (without fail) assume that someone else will help, or that the person having a heart attack is just a weirdo trying to get attention.
Now apply this same concept to the release team: with no single point of ultimate responsibility, things like deciding when to tag, when to freeze, what to name releases, etc. Whenever these discussions have come up on the release-team list (which I've monitored with some regularity), it takes a week to decide on any action.
So my suggestion for improvement is that for the next release, 4.0.1 or 4.1 or whatever we decide will be the next release, we appoint a release team coordinator for that specific release who can help to steer the discussions, and make more rapid decisions where they are needed. The release coordinator would not have sole responsibility, but could be considered the "whip" (in political terms) that makes sure that websites get updated, things get tagged, and decisions are made in a timely fashion.
Those people that are release-team members (and not just passive observers who like to throw their two cents in every once in a while, like myself) would report to this individual about the state of their activities, rather than just reporting to a list and hoping someone else notices.
That's what I would do to improve the release team for future versions, based on my observations of how things worked for 4.0. If it were up to me, I'd even make you, Tom, this official whip since you are apparently very good at it (see re-licensing progress before and after you got involved - big improvement!)
So like I said in my previous blog entry, my main problem that I see with the release-team is the decision making inefficiency, and now I've made my suggestion on how I would like to see it improved. Hopefully a few of the perceived hiccups in 4.0 can be smoothed out this way for 4.1; or if you (or someone else) have a better idea - please run with it.
Cheers
- Log in to post comments