adding more status/next action/deadline/actor fields would help, if trac supports that (could be simple free-form text fields, or selections),
FYI, Trac is bringing us "customised workflows", which will allow us to do some of this:
http://trac.edgewall.org/wiki/WorkFlow
In particular we'll be able to add new ticket states to indicate that the ticket is waiting for feedback from the submitter, or some other dependency. I wouldn't be in favour of just adding new fields to do this right now, we already have too many fields.
that looks promising. although the idea still seems to be to have few states, leaving it to custom fields to specify details. so there might be a single "waiting" state, with an action field specifying what one is waiting for (someone getting an definite interpretation of a spec, someone contacting the gcc/ cygwin/whatever team, someone implementing a newer, better language feature that will make the issue obsolete or easier to deal with, etc), a date field specifying when results from that action are expected (or a reminder should be sent), and an actor field specifying who is looking after that action. and if the actor finishes the action, a click on the "done" button would take the ticket to "idle" (waiting for the next action to be determined) or, better, the next action to specify would be obvious, going directly back to "waiting". this combination of two extra states+three one-line fields would be more flexible and less complex than trying to capture all eventualities in pre-designed fields/states, as trac currently aims to do. you name one part of the current problem: too many fields not relevant to every ticket; i named another: too few relevant fields. having more general fields could address both parts. i can understand if you want to hold back until the next trac release, as that seems to switch a few things around. it is just that if i think of the current state of ghc's trac as wasting your time: - if you wanted to go through all tickets to figure out their state and adjust their milestones, i estimate that could take anything up to a full day; so long, in fact, that you decided not to do it for this release - if you wanted to figure out which tickets are pending full implementation of open type functions, you'd have to go through all type-system tickets - etc. etc. if, instead, all the information relevant to organisation (as opposed to information relevant to fixing) were available in ticket fields, one could go through all tickets in an hour (without ever having to wade into the ticket history/comments), and many things one might want to figure out could become a simple trac-query instead of a full search. an overview page translating states to colour could tell at a glance which tickets are actively waiting, and which are idling or overdue (hence need attention). in fact, since all information about a ticket state would be visible to everyone, from the ticket fields, there would no longer be a need to go through all tickets at every release just to reassure submitters that their tickets weren't overlooked. in other words, i'd classify this meta-ticket as both urgent and important: urgent because the current system is becoming unwieldy, important because a reorganised system should save you a lot of time. claus