Subject: [Tools-discuss] [Fwd: Re: Last call tools]

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 17 Oct 2005 00:37:52 +0200

I just sent the following to [email-masked], but I'd better send a copy
to this list too, as it's definitely on-topic.

	Henrik

> -------- Original Message --------
> Subject: Re: Last call tools
> Date: Mon, 17 Oct 2005 00:35:32 +0200
> From: Henrik Levkowetz <[email-masked]>
> To: Sam Hartman <[email-masked]>
> CC: Brian E Carpenter <[email-masked]>,  [email-masked]
> References: <[email-masked]>	<[email-masked]> <[email-masked]>
> 
> 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
> [email-masked] 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.

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 17 Oct 2005 03:58:17 +0200

Always wondered how you managed to do so much with that BCP issue list, 
Henrik - thanks again!

>> issue tracker), and became convinced that there must be a better way.

One of my frustrations with trying to do the same in USEFOR is that about 
90% of *everything* is basically chaff - "me too", distractions, tangential 
discussions, quotes from other people's messages.... it's important that 
the tool keeps track of these automatically (if possible) - but it's as 
important (I think) that the tool makes it trivial to read these messsages 
*once* and then ignore them unless needed.

Thus, I'd like to have tool functions that operate on the discussion tree 
to say things like:

- Message irrelevant. Don't show in default view.
- Thread not related to issue. Don't show in default view.
- Thread "from here on down" is a new issue. Create new issue, and move 
thread to it (keeping a pointer)
- Thread "from here on down" is a different issue. Move.

I'd like the normal case of "review an issue 5 months later" to be looking 
at the 5 *relevant* messages, and not have to read through the 20 
irrelevant ones over and over again.

But that's a lot to ask in a first version....

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 17 Oct 2005 07:26:10 +0200

Hi Harald,

> *once* and then ignore them unless needed.

Good point.  I'd already planned to have the quote parts of messages nearly
invisible in the default view.  I see that some additional functionality
will be needed, though.

> - Message irrelevant. Don't show in default view.

Right.  

> - Thread not related to issue. Don't show in default view.

Right.

> thread to it (keeping a pointer)

Right.  A variation on the next one, but with a link.

> - Thread "from here on down" is a different issue. Move.

Right.  This one I'd already planned for.

> irrelevant ones over and over again.

Well, yes.  Happily, with web deployed tools, it's easy to "Release Early,
Release Often" :-)

	Henrik