Re: [Evolution-hackers] Thread Stealing

["Garreau\, Alexandre" <galex-713 galex-713 eu>]

Le 30/05/2018 à 09h00, Milan Crha a écrit :
> On Wed, 2018-05-30 at 01:43 +0200, Garreau, Alexandre wrote:
> > If you inspect the In-Reply-To headers you’ll see none of these is
> > marked as an answer to another, yet References mark them because some
> > of them do reference the other ones.
>
>       Hi,
> I highly doubt any regular user even knows anything about the
> internals. They care of the result. And what you did has the result as
> shown in the attachment.
>
> That's a very good habit to discuss one issue in one thread (or even
> bug report), though I agree it's not always possible. While you think
> the things are related, then the X-Mailer has nothing to do with Reply-
> to-List (it just happened that you wrote both messages), still if I'm
> not interested in the X-Mailer thread then when I collapse it (or mark
> it to be ignored) I lost track of the other threads.

Wouldn’t it be more practical then not to nest inside other threads
messages that *don’t* have an “In-Reply-To” header?

> I also expect that you did put some effort to have the References
> header filled in the other messages, which just shows that even you can
> do that manually, regular users will not do it, unless they have tools
> for it.

I have a hook that looks for references to other messages (through
Message-ID for instance) in the body and add them to “References”.  The
same way I can in my UI select several messages, then do “Reply” and
this way reply to several messages, and get several Message-ID in
“In-Reply-To” if I want.  That stays pretty straightforward, and don’t
require that much “extra” tools or commands.

However I indeed never saw any user-agent correctly handling threads in
that they won’t thread messages without “In-Reply-To” (sometimes they
don’t even read it in any way and only use “References” to construct
threads >< how random), or that have the ability to correctly represent
a thread that’s not a tree but a graph (git has the ability to do that,
I’d expect an user-agent to do the same, and I plan in the future to put
MaGit code in my User-Agent to get that output).

> Anyway, we diverged from the subject from my point of view, we just
> discuss our habits and preferences, which obviously differ. Each has
> its pros and cons, I'm not questioning that.

Yet “it’s *your* opinion and everything can be good or bad and that
doesn’t matter” is not really a constructive conclusion: I like to
interpret standards not because of authority, but because they help
building interoperability while preserving functionality.  If there are
different pro and cons we should find the simpler method to make the
more easily people able to get all the pros they want and avoid all the
cons they want, depending on their preferences and what’s technically
possible, while preserving interoperability.

> My personal past experience is that changing someone habits is pretty
> hard (near to impossible), no matter what any document can suggest as
> the best practice. Again, consider regular users, corporate
> environments (top posting), incorrect quoting,

Habits are not magically originating from the sky after having popped
from nowhere, new habits can be analyzed and influenced by ergonomy, as
well as old habits can be changed by a new environment (I don’t think
going from GNOME 2 to GNOME 3 did preserve all “old habits” without
changing anything, beside orienting people to MATE), and better: old
habits *consequences* and implications can be changed by the underlying
system habits build on and use.  If the habit is “press the big button”,
and from one precise meaning that was abuse that button begins to offer
*the* simpler and most-of-time appropriated thing to do in this case,
then usage become better, without changing habit.  Software should adapt
to habits, not the reverse, I agree.  But what software do in this case
should depend on interoperability and functionality, not on “preserving
the old”, like an old habit would, because software isn’t habit and one
change may result in non-proportional (potentially positive) outcome.

> when people cannot distinguish between instant messaging and e-mail
> (they try to use instant messaging habits in e-mails, huh) and so on.

Beside synchronicity and presence, if quick enough with close-circuit
enough I can see how mail might be used in a such way, especially as
things may become quicker and software better, I don’t see this as a bad
thing, only a new usage.  And since currently mail is an old,
interoperable and established standard, building new stuff on it, be it
with adding extensions, seems to me a lot more powerful and natural than
building anything on IRC bots or, how it nowadays has become sadly
systematic, web browser.  I still prefer exchanging one sentence per one
mail per minute in a “conversation-like” view, than passing 3 hours
trying to make XMPP work, waiting for my browser stop to freeze in front
of Matrix, find an unambiguous way to specify threading/reply-to and
formating in IRC, or using any centralized protocol.