Here’s a bit of Tinderbox show and tell. Like I’ve said, it’s a deep tool. The word “deep” was bandied around a lot at the Tinderbox Weekend, with good reason. Here’s one of the ways I use it.
One of the first serious tasks I started using Tinderbox for was a project organizer to keep track of what was going on for work. I’d been using a rather monstrous web-based bug-tracker application at my old job, which was good for some things but bad in a lot of ways: it took a very long time to enter the information, and while a few dozen fields were required for input, the granularity of the fields was often not relevant to the problem. Most people either grudgingly used the system or fixed things on the sly.
I swore that I’d not do that in the future. When I got into my new situation, I found myself responsible for a lot of things; not only for coding as tasks came up, but for knowing what’s going on in the entire system. There’s no one else to pass the buck to, so I’ve got to be on the ball. I looked into some other pre-made solutions, and considered writing my own tool with a database backend. I ended up using Tinderbox because it seemed lightweight, adaptable and flexible.
After this weekend I spent some time refining my project organizer. The first thing I did was use the Rules (new in 2.4) to show me exactly how many incidents were waiting for attention. There’s always more to do than I’ve got time, but knowing exactly where everything stands is a good thing.

The second thing was that I decided to see what Map View could do for me. Project Organizer, the way I’ve set it up, is big gnarly outliner. For example, I’ve got my projects set up like so:

Inside each project are a bunch of bugs, features, and so forth. This is informative in its own way, to be sure! But a little time with the Map View on the same data and I was able to get a lot more perspective on what was up.

This probably doesn’t make any sense to anyone but me, but it conveys a vast amount more than the outliner ever can. And it’s not either/or. It’s both; I get my outline cake and can eat it too.
The third thing I did was take better advantage of colors. When I put something into the system, I assign it a priority, which defaults to 5. If the priority is less than 4, it’s a low priority item, a “might have.” I created a few agents to lighten the color of the “might haves,” so that while a bug is red, a low priority bug is light red.

These colors are active both in Outline and Map View now — thank you Tinderbox 2.4 — which ends up giving me a lot of information at a glance. The mix of objective (red is an unambiguous bug) and subjective (placement of projects in the map) is a good one, and it gives me a great overview of what’s going on. It’s not a project-management-for-everybody solution, yet it fits what I’m doing right now like a glove.