Hi Sam,
I have a design for an issue tracker adapted for IETF use lying
around, but haven't had time to implement it yet. I think it may
match the requirements you place on a solution in your note below.
The idea is based on my experience when doing issue tracking for the
IASA BCP during December and January nearly a year ago. Some days
with intensive discussions I spent as much as 5 hours doing cut and
paste from mailing list to issue tracker (RT - a good and competent
issue tracker), and became convinced that there must be a better way.
The idea is based on our way of working, and on the premise that
almost everything needed by an issue tracker is actually already
contained in an email message. (Subject - reporter - threading
by "In-Reply-To:" header or subject - date - report details...)
The tool could be seen as an merge of a list archive and an issue
tracker. All issues should be posted to the list, matching the way
we work today. Adding a few particular keywords (based on Bernard
Aboba's well thought-out template for reporting issues to the EAP
list; http://www.drizzle.com/~aboba/EAP/eapissues.html) to a message
could trigger the automatic creation of an issue, or a document
editor, chair or AD could use the web interface to the list archive
to mark a message or a part of a message as an issue.
Any follow-up messages to the initial message of an issue would be
added to that particular issue unless the chain was explicitly
broken by the document editor, chair or AD.
Similarly, going back and flagging an earlier message as an issue
to be resolved would automatically bring along all of the follow-up
messages into the list of comments on that issue.
Most (all) of the management of the issue tracker side of the
mailing list archive could be handled simply by following up on the
threads on the mailing list, supported by recognition of certain
keywords in the subject line or start of the body (E.g.,
"Text needed:", "Text proposed:", "Issue resolved:"), but management
through a web interface would also be supported. Information about
status changes done through the web interface would be sent to the
list by the tool.
For most issue trackers, this way of working would seem pretty
roundabout, which probably explains why there isn't such a tool
available (as far as I'm aware). But for our way of working, I think
it might be just the ticket.
Comments on this idea would be most welcome, either here or on the
tools-discuss@xxxxxxxx list.
Regards,
Henrik
on 2005-10-16 22:50 Sam Hartman said the following:
> I I think that I want multiple views/interfaces to the same data.
>
> I like email for participating in a last call discussion. I get to
> use my UI; there is a well defined functional interaction protocol
> (IMAP, SMTP) for exchanging the information and for allowing me to
> thread it, reply to it, handle it offline. I have a lot invested in
> being able to deal with email well because I get a lot of email.
>
> However email is very annoying for seeing if all the issues have been
> dealt with or seeing what the current consensus summary of an issue
> is. A webpage would be great for that.
>
> But if all I had for last call comments was a webpage I'd tend not to
> make as many comments or be as active in discussions.
>
> We certainly don't want somethnig as simple as the datatracker. For
> example, discusses are entered in the datatracker. But we do a
> horrible job of tracking the actual discussion that leads of to
> resolution of discusses.
>
> I agree we should have better tools. I would be very skeptical of a
> solution that forced everyone into one interaction model.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf