I agree that ticket systems and bug trackers cause some headaches for developers. When you have a problem on the shelf, you're compelled not to think about other things, which may be either nicer, or more important.
But there's a lot of value in being able to track things. You don't need a task list loading up your head in the same way, and for a distributed project it's vital for communication purposes.
One suggestion might be to have two lists: the central repository for bugs, which get voted on (and the votes diminish over time, like a hacker news of bugs/issues/enhancements). And then for each person, a 'shopping list'.
The idea is you don't want to take on too many tickets, because after a while, they go 'bad', like groceries -- they just stay in our fridge and we don't finish them.
You also want to be able to judge impact versus the time you think it will take, so you optimize for that -- something like the number of votes divided by the number of hours you think it will take you will give you the priority.
Heck, this is actually starting to be a good idea. Maybe I should throw up a little HN clone for tracking, and see how it goes.
You're not alone. I was talking with someone from Google who works on the Gmail support team, and has an interest in user-to-user support, in general, the other day, and she was asking me about how hard it would be to convert the newly Open Source reddit into a ticket tracker.
I think it underestimates the importance of other aspects of a tracker--but my lack of confidence in the idea may be based on my own prejudices based on years of working with traditional issue trackers. I expect to receive an email when a new ticket is filed, so we'd need to add notifications. I'm missing emailed ticket submission (I miss it in my current tracker, and will be moving to something else because of this lack), so you'd need to add email ticket submission. Assignments are a core part of any ticket tracker--you need to be able to take ownership of an issue so that others don't spend time on it unnecessarily (though others should be able to follow it).
But, I do think several things would shake out of the model that are hard to do now:
Priority. The less someone knows the more important they believe their issue is. So, it's basically a no-op field in most trackers I've ever used. The developers might use them to good effect, and a few advanced users. But since greater than 50% of priorities are set incorrectly, it's a useless field for sorting (and my current tracker doesn't let me remove it from the form, as it is the primary sort key!). Since everyone gets a vote, priority as "hotness" would be a great improvement. But, it assumes your whole community is looking at the tracker, which is extremely unlikely.
Discussions. People rarely talk on issue trackers because the conversation tools are weak--the focus is never on making it work really well for discussions. reddit/HN have great threaded conversations, and you can vote on what's relevant and accurate. I would very much like better discussions in my tickets.
But, I think it would require something like a total conversion to this sort of forum as the entirety of your forums/mailing list/bugs system. Which might be a good idea for someone starting from scratch. If you have sub-reddit style categories, with one for tickets, that'd be a pretty effective system, I think. Though you can't currently "close" a thread on HN or reddit, and call it "fixed"...so that'd be something to add.
Anyway, I'd love to see how an implementation like this worked out in a reasonably large community. It might be something we'd want to try on our Open Source community site (our commercial site is already too set in its ways and customers hate change). But the Open Source site needs a bit of a refresh...it currently uses SourceForge for its tickets, which kinda sucks.