ANNOUNCE: GHC 6.8.1 Second Release Candidate

[Claus Reinke]

> > 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