Hum, I added the <> because many text mailers (like gnus) treat the content between these as links (as a complete string, which means <http://gnag.gag/ad adadda.html> will be completely handled, unlike http://gnag.gag/ad adadda.html that would make a broken link).

I do not know if there is a standard about that. It is hard to make a decision that will help you but potentially be a pain to others.

That being said: is there no way to click (or push enter) on a link with mutt? Hu, how can someone use such tool :P

Even less information? Arg, it will be really hard to know what it is about. We already seriously removed a lot so far, do you think we should go even further :] ?

"I meant that having to use a browser to send a notification may not be necessary in the future (ie if we get such a mail interface), and that should be taken into account when making long-term decisions."

You are right. But we cannot (okey, we did that in the past) consider ok to send each time a mail with as many information as the item webpage. The item webpage must be exhaustive because we need a place like that at it fits well this purpose.
Indeed, the day a mail interface is implemented, it should provide a way to get exhaustive information also. But the mail is currently used mainly as notification, and will still be used as notification; as such it has constraint the webpage does not really have.

---

Side note: this time, theoretically, we should not get timezone conflicts (you are not in Europe/Paris timezone?)

Should Start On: Thu 11/18/2004 at 23:00 => Thu 11/18/2004 at 00:00
Should be Finished on: Fri 11/18/2005 at 23:00 => Fri 11/18/2005 at 00:00

since the relevant bug is hopefully fixed.

Now ", tracker #nnnn (project unixname):" is added to the first subtitle.

I hesitated with ", tracker #nnnn, project unixname:" but was unable to decide so I picked the first.

The follow-up is IMHO the most relevant part of a notification. So the solution I have in mind is to write the follow-up at the top, and then, put the other infos.

If people like the ones working at CERN do need the changes to be placed before the follow-up, then consider removing the "changes:" title, as well as the "follow-up comment #xx" one, and the "---" separator; to sum up, use RFC822-style organisation:

change1: value1
change2: value2
<blank line>
follow-up

and then, all the additional information needed, structured whatever way is needed. Using this RFC822-style, it is obvious which part describe the field changes and which part describe the follow-up, so no additional presentation text is needed.

Regarding the history, quoting only the latest comment is now necessarily good. In this very case

> Hum, that's correct, the original subject does not permit to deduce it.

would not remind me much about this task within a few weeks.

> But they are more or less forced to [use a browser] anyway, if they want to further comment the issue.

I do not dispear to see / code a mail interface to the trackers in the future.

Note that if we get a mail interface, and maybe a quoting facility for the web, then it would be up to the users to select the history they want to include in the notifications. Just like we do when discussing in the mailing list. Items would be bigger in the database (because of all the duplicated quoted history), but posting the history in notifications would then be rather useless and that would solve the problem of including history.

The drawback is that web users may get bored to see a lot of quoting in the comments; in this case, maybe we should provide a way to filter such quoting for web users. If we get super-clever when comparing the quoted texts, we could even provide an auto-threaded wiki-discussion-style way to present the follow ups, but that can wait :)

Hum, that's correct, the original subject does not permit to deduce it.

Note: normally, in a mail, the subject of the mail should be enough as regard of reminding the context.

So I guess it is also a matter of updating correctly the item title field. Or maybe comments should have titles?

As far as I am concerned, I find it difficult to get the essential information in the previous version: I often 'miss' one-line comments among all the separators and blank lines. It is good when you have the relevant information in the very first lines of the mail (no scrolling needed).

I don't care about most of the metadata fields, ie I only care about whether the item is open or closed (plus why it was closed), and who is working on it.

The disappearance of the history is very inconvenient at the moment, because Mathieu is running through bug reports that I don't remember of, which made me load the tracker www page each time.

I think I would vote for a solution where you basically have only the last reply at the top of the mail (no separator, no title, no heading blank line), then the notification as in the current trunk. The history part should be in a consistent order; previously you had the original submission (oldest part), then the follow-ups from the newest to the oldest, which is sometimes not easy to read.

It would also be possible not to include all the comments, since it tend to generate message that are bigger than the Mailman default size of digest (and you receive 1-mail digests at savane-dev ;)).

Also, did you consider templatizing the notifications?

This is definitively more easy to read, since most of the time only new data is sent. On the other side, we're loosing some context info. However it's very easy to follow the ticket link, and have it all in a nice Savane-formated page. I like this compromise a lot, congrats for those efforts !

Sure, I will do it.

Hello Dig,

Can you submit a specific task for your proposal?

I think I'm going soon to try to improve the mail notif by removing the overview content. Someone also (dont remember who) suggested to skip things like "posted by" as we can assume the information is already in the from headers. It makes sense to me.
Without the overview section, we gain a lot of flexibility. Because it means, more or less, than most sections just get removed.

I intend to make a branch soon for this cosmetics changes.

Efforts have been made in the latest development. The result is far from perfection but lisibility is probably now better.

I expect more improvement to be made for notification in the future. But that a part hard to improve. Most of the time, the complainers have a very specific vision of what would be the perfect notification while they do not have a clear idea of what the notification could contain. For instance, persons that usually tracks issues where item update only contain 2 lines followup comments tend to think the separators to be overly line consuming; but if they were receiving followup comments of 50 lines including bits of code, with 6 fields being updated, they would clearly understand the waste of one line as separator that greatly enhance lisibility.

My personal stance is that what should matters most is not the amount of lines used by the lisibility in itself. Tests should always be made with item with long comments and many field changes.
Having less information is usually convenient for regular users, since they know exactly where they should be looking. But the interface should be newcomers-proof as much as possible.
For instance, a first paragraph saying the mail is a notification about this item on this tracker on this installation is probably useless for many users. It is not for newcomers, it is not completely the case for persons that uses several instance of Savane. One could interpret the mail header to get clues about the context; but it is not sure at all.

Many users never read what is written, even when should. I tend to think that it is up to them -- it is their problem in the end if they missed something by not reading. But users that do read what is written should never miss something because we were pretentious enough to assume that everything is crystal-clear and does not require any comments.
I personally rarely read some parts of the Savane interface. I almost never read the Label of the fields (like Category, Privacy), I only click on the select boxes. Maybe it would be even more confortable to me if there was no such label. It would be possible to get a form even smaller, with less lines wasted. That would be me just taking into account my own usage of Savane and what would be very efficient for me.
It is probably the way Emacs was designed. Emacs is powerful, I use it everyday. But it tooks me weeks just to understand how to do the most basic things.
Savane should not be an Emacs, should not be a tool designed for computers experts.
If we can make happy both computers experts and the rest of the world, ok. But when we cant, we should make an effort towards the rest of the world.

These two points (items will plenty of info, problem of accessibility to end user with little computing knowledge)
are why the latest changes made to notification did not reduced verbosity and separators line consumption.

I'd like everybody that want to work on notification content improvement keep these two points in mind. It does not means that separators and verbosity should never be changed. It means that when we'll speak about changing it, we'll do it with in mind that the result will be as easily understandable to most users.

-------------------------------

That said, I wonder if the section "Overview" is justified in mail changes notifications. Maybe it should be sent only in the first mail and the update notification should only mention what changed.
It would greatly reduce mail size and would allows us to change things more easily, as we would no longer need big OVERVIEW/CHANGES separators.

That's, I think, a starting point for future improvements. But I have no clue whether the overview section is felt as important to users or not. I know that a few said it was useless. But a few complainers is not enough to know what the others thinks.