Many people use the "Preview pane" feature of their mail client, which shows the first 10-20 lines of an e-mail in your face so you get the jist of what it's about without reading the whole thing.

However, issue e-mails have the information I actually care about (who said what thing) *after* the information I care less about (what the current status of the issue is). So as a result, paging through my infrastructure list e-mails, for example, results in previews like:

Issue status update for 
http://drupal.org/node/198873
Post a follow up: 
http://drupal.org/comment/reply/198873#comment-form

 Project:      Drupal.org infrastructure
 Version:      <none>
 Component:    Other
 Category:     tasks
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  greggles
 Updated by:   sepeck
 Status:       active

rather than:

Issue status update for 
http://drupal.org/node/198873

d.o. has been slow lately?

sepeck

---

 Project:      Drupal.org infrastructure
 Version:      <none>
 Component:    Other
 Category:     tasks
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  greggles
 Updated by:   sepeck
 Status:       active

Post a follow up: 
http://drupal.org/comment/reply/198873#comment-form

...which I think would be more optimal.

Comments

webchick’s picture

I should clarify. The pertinent information in that status update is mostly what project it came from, but that's found in the subject line: [infrastructure]

dww’s picture

Title: Usability: Re-order contents of project mailstlists » Usability: Re-order contents of project issue emails

webchick: but if there are diffs to the issue meta data, those are probably at least as interesting as the body of the message, no?

I'm also worried that the issue status will get lost if it's after the body of the comment, especially since there's nothing to clearly distinguish it from the rest of the comments in the thread (which arguably we shouldn't always include at the bottom of each email, but that's a separate issue).

Anyway, I'm torn. This doesn't immediately seem like a clear win, but I won't kill the issue yet, either. ;)

webchick’s picture

How about just this then?

Issue status update for http://drupal.org/node/199178

Issue changes since last reply:
Status: active => patch (code needs review)
Assigned to: Anonymous => dww

===

Why, webchick! That's the best idea I've heard all day! ;) Here's a patch! ;)

-dww

Because the subject line is:
[project_issue] [feature] Usability: Re-order contents of project issue emails

I already know it's for the Project Issue Tracking module, and I know it's a feature request. There's definitely little sense in repeating that information again, unless of course it's been modified. So simply include those values that have changed since the last reply, at the top of the message. There are times when there will be enough of these (moving an issue to a totally different project, for example) that the changed statuses will bump the actual content far enough down that it gets lost, but that's pertinent information to know in that case. In all others, the status changes will be minimal, if they exist at all.

dww’s picture

Version: 5.x-2.x-dev » 6.x-1.x-dev
Issue tags: +drupal.org notifications

Moshe suggested the same over at #886310: Mobile phone friendly emails which I've marked duplicate with both this and #15380: Allow to configure content of issue notification e-mails.

But yeah, we should fix this...

sun’s picture

- I like the suggestion of only outputting the property changes at the top. Most often, only the status is changed. Even more often, no issue properties changed at all, so you'd see the comment directly at the top.

- I also like the suggestion of outputting all current issue property values below the comment. (but of course, above the full issue history)

- The suggested new diff format of "old » new" is a good one, too, but does not work for all properties. AFAICS, at least issue tags would still have to use the current "unified diff" format.

--- That said, I'd also love to see a change to the issue title.

- I wonder whether this change would have to be user-configurable at all. (don't think so)

moshe weitzman’s picture

Status: Active » Needs review
FileSize
3.1 KB

As per #5, attached patch shows changed metadata at top and full (new) metadata below the body, but above the (optional) issue history.

No change to way we show the diff (unified vs. inline)

dww’s picture

Status: Needs review » Needs work
FileSize
4.75 KB

Sorry, Moshe. Local testing isn't working at all. The metadata changes never appear, nor does the summary of current values. The handling of the $summary variable is totally broken. This whole function is insane. Here's a partial attempt, but it's still not working as expected. I don't have time to keep debugging this and actually getting it working, but if someone wants to build on the changes I've made (or start over with a better approach) cool.

mgifford’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev
Issue summary: View changes

I'm assuming this is still needed for D7.

drumm’s picture

Status: Needs work » Closed (works as designed)

The email notification I got for this issue shows it is fixed.