Peaceful Coexistence with an Issue Tracker

[Stephen J. Turnbull]

Drew Adams writes:

 > I see; it's the user's problem. Each user should customize the mail
 > client.

No, you clearly don't see *at all*.  You apparently have read a book
on HCI (and maybe written a half dozen), but that expertise is going
to be essentially irrelevant for maybe three months, until the system
itself has somewhat shaken down.  Your incessant complaints can at
best slow that process down.

Some useful principles in introducing an ITS:

1.  An issue tracking system (ITS) is in service to the *maintainers*.
    (For this purpose, the maintainers are Stefan and Yidong ex
    oficio, and those others such as Miles, Eli, Jason, Juanma, Glenn,
    Ken'ichi et al who have assumed reponsibility for one or more
    subsystems, and who are reliably available to deal with problems
    promptly as they arise.)  We "just users" should mostly just grin
    and bear it until they've decided what they want to do with it.

2.  An ITS is *not* a mailing list, although it manifests on certain
    mailing lists in various ways.  Trying to handle it in a standard
    mail client is not going to be terribly productive.[1]  Trying to
    force the ITS into a format that is friendly to Outlook and RMail
    (as it exists today) is a prioi a BadIdea[tm].

3.  ITS issues and mailing list threads need not be co-extensive, and
    often should not be.

4.  As a consequence to 1--3 inter alia, add-on software will be
    written to enable the maintainers and others to handle ITS traffic
    and ITS issues efficiently. Some is presumably already available
    from Debian, but that will need to be extended, I suspect.  For
    obvious reasons, that software will be written in Emacs Lisp.

I would recommend to users who prefer non-Emacs MUAs that they filter
ITS traffic into a separate mbox, and use an Emacs MUA to read it.  In
that way they can profit from the hacks of others, and maybe
contribute some themselves.

A good milestone for when HCI issues can usefully be raised would be
when Stefan and Yidong have figured out what kind of regular status
reports from the ITS are useful to them.  At that point the issue flow
has probably started to stabilize and the maintainers have a better
sense of what is and is not necessary to their usage of the ITS.

Footnotes: 
[1]  N.B. Outlook doesn't even qualify as a standard mail client here.
It has a myriad quirks, so that catering to Outlook means that you
cannot take advantage of a large fraction of the capabilities of
RFC2822- and RFC1035-conforming MUAs.