As I wrote yesterday, one of the reasons that I don't think we need a trouble ticketing system here is that we are not all that busy with requests; in fact, the average number of open requests is generally zero. I think that this is a good thing, and that frequently having more open requests than sysadmins or even having all of your sysadmins busy dealing with requests is an important danger sign.

It's a danger sign because it means that your sysadmins are too busy to do long-term work. Instead, they're either doing things that need to be automated, or spending their time running around throwing water on a succession of fires, or in general being reduced to being operations monkeys who carry out standard procedures (which is not a good way to keep good sysadmins, because frankly it's boring). In short, you're too busy dealing with the now to be building the future. This is not a good place to be in; the future always arrives sooner or later.

Sysadmins that are 'idle' from the perspective of a trouble ticketing system are sysadmins that have time to work on larger projects and to prepare for the future. And you need more than little bits of time here and there, for the same reason that developers need it; you need solid blocks of time where you can focus on a single thing instead of playing whack-a-mole with trouble tickets.

Thus I consider it an extremely healthy sign that we have so few requests that a 'level 1' mailing list setup can handle it. This is the kind of environment you need to produced things like cheap iSCSI based fileservers, upgrades of complex mail systems, and transitions of core routers in a complex network environment.

(My personal feeling is that trying to put long term development projects in a trouble ticketing system is not going to work really well. It's the kind of thing that I would only do if I had to use a TT system for everything because of some outside mandate.)