| Issue 311: | Improve formatting of emails for faster reading/filtering | |
| 29 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Gerrit sends out a lot of email by default. I'd like to change it (or provide a setting) so that it won't email me when I: - add a reviewer - publish comments I already know what I've done in Gerrit, getting a confirmation email isn't necessary (at least for me). I've had a few users complain about the volume of Gerrit email and I think this would help.
Oct 29, 2009
#1
sop+code@google.com
Status:
Accepted
Nov 3, 2009
Is there a use-case for needed emails of my actions in Gerrit? I can't think of a reason for a user needing a copy of the email that they requested a review or commented/rated a change. Maybe it could protect from a malicious user hacking an account and requesting lots of reviews without the user's knowledge? ;) I don't mind adding a setting, but less work = better.
Nov 3, 2009
Gerrit auto-CCs you on everything it writes, because originally it was sending those emails with your name/address as the From in the message header. To stay honest about what we are saying on your behalf, we CC'd you. We've since changed the behavior such that it is no longer the default. So there is less of a need to keep you in the loop when we say something on your behalf, its most likely not coming from you, but is instead coming from the generic service address the administrator has configured for the daemon. I think we could do: If sendemail.from = USER: CC unless sendemail.ccsender is explicitly false. Else: CC only if sendemail.ccsender is explicitly true. Does that make sense?
Nov 3, 2009
Yep sounds good to me. I'll try to get to it soon.
Nov 6, 2009
I was trying to think of other ways to reduce the time I spent reading Gerrit emails (which is sometimes about 1email/minute). I had been thinking that removing my own actions would help (this ticket), but I think all of the other emails are necessary. One way might be to improve the subject lines, e.g.: Commented; ../foobar-project - <summary> - Give an action out front, so that merges and people just changing scores can be ignored on most changesets being watched - Don't write the branch name and changeset id. I don't think these have ever helped me. I doubt many people recognize the SHA ids, and each changeset will only be for one branch, so the email body or just the Gerrit changeset can show that. I've never found a situation where I change my action based on which branch it is going to. (Maybe others using more branches find this helpful, though) - Don't write the full project name. Some of our projects are pretty long and it takes up a large portion of my subject area in Thunderbird to show it. Right now with the other information, the summary is normally cut off. Ideas/suggestions?
Nov 6, 2009
(No comment was entered for this change.)
Cc:
m.bnovc
Nov 6, 2009
@m.bnovc: You don't have to modify the issue to CC yourself, just star it. Regarding your idea in comment 5 to alter subject lines by action, this breaks threading in lesser email clients, especially GMail. Everyone I know at $dayjob (including myself) feels that its more important we keep all messages from the same change in a single conversation thread. - We could reword the body slightly so the first sentence is more clear about the action taken. This would make skim reading faster. - The branch name in the subject has been heavily requested by peers at $dayjob because it helps them to filter "important" (next release) vs. "unimportant" (the release after the next release). Removing it is probably not possible. - The Change-Id abbreviation in the subject is likely overkill. We might be able to get rid of it. It takes up 8 or 9 characters and being a big jumble of hex digits makes it nearly impossible for a human to follow. I don't copy them out of my inbox subject list, I open the message and click a link within the body to jump to that change. Most people probably do that, especially in GMail where its hard to select subject text due to 1-click being 'read thread'. - Full project is probably also overkill. Most projects are unique with just the tail portion. But I do know of someone who has 3 different Android trees loaded on their server. In such an environment the 1st path component and the last path component would be necessary to help sort reviews. It might still be worth trying just the last component and see if they complain. :-) So I think we can take a few specific actions on this: - Do what I said in comment 3 above with sendemail.ccsender to try and reduce sending yourself a copy of actions you have performed. - Remove the Change-Id from the subject line. - Show only the last component of the project name in the subject. - Consider rewording the first sentence of each message template to help users more quickly skim read and decide how much attention to pay to this message.
Cc:
-s...@google.com
Nov 6, 2009
I would much rather have subject information than threading. I don't think threading is important in this situation or JIRA because the history is recorded in the product, and I can get to it by clicking the link. If I want to see what someone was replying to, etc., then I do so in Gerrit. Granted others may use it differently. Perhaps this could be some option in the future, which would also cover the case of the person you mentioned with three trees. I agree with the rest of the changes listed at the bottom of your post.
Apr 5, 2010
Issue 525 has been merged into this issue.
Apr 5, 2010
I would just like to add that in my particular situation, Gerrit ends up sending me so much email that I really have no choice but to filter all email from Gerrit to /dev/null. We have a lot of developers, and all of their changes funnel through a fairly small number of approvers. The approvers tend to get so much email that they fail to notice the messages that would actually be important. The ones, to me, that I actually should be notified about: - There is a new upload for something that I've given a negative review for. I need to respond to this, in order for this change to get anywhere. - Someone has explicitly added me as a reviewer to a change. Basically, it would be nice to be able to only get email from gerrit about things I actually need to do something about. Just as a statistic, for the month of March, I averaged 62 emails a day from Gerrit. For the most part, everything else is just noise. As it stands now, I've had to tell people to notify me out of band (as in an email directly to me) about something I need to act upon. David
Apr 8, 2010
Issue 530 has been merged into this issue.
Jun 15, 2010
@bklarson Have you made progress on this or would you like someone else to take a crack at it?
Jun 15, 2010
Hi Nasser, I started work on the "Don't CC me on changes I make" improvement, but got sidetracked with other projects. If you can take it over that'd be great - I'm not sure if/when I'll get to it.
Jun 15, 2010
(No comment was entered for this change.)
Owner:
mf...@codeaurora.org
Jul 13, 2010
https://review.source.android.com/15765 adds a flag "CC Me On Comments I Write", with the default being off on user accounts. So you now have to opt-in to being spammed by yourself. I'm leaving the bug open and assigned to mfick as he's also working on other formatting issues related stuff mentioned in comments above.
Summary:
Improve formatting of emails for faster reading/filtering
Jul 27, 2010
I was curious if any progress has been made on this in the last month? Does this need to get re-assigned again? I think someone at the office I work at could probably investigate this issue if Qualcomm/CodeAurora hasn't had time.
Jul 27, 2010
mfick is working on it: https://review.source.android.com/16043 https://review.source.android.com/16037 https://review.source.android.com/16019 https://review.source.android.com/16015
Aug 12, 2010
mfick's series was merged, it will be in 2.1.5.
Status:
Fixed
Labels: FixedIn-2.1.5
Aug 12, 2010
Thanks mfick (and sop as always)! This will be great to have.
Aug 19, 2010
(No comment was entered for this change.)
Labels:
-FixedIn-2.1.5 FixedIn-2.1.6
Aug 24, 2010
(No comment was entered for this change.)
Status:
Submitted
Aug 25, 2010
Now that the template approach has been merged, here are my proposed fixes to the templates. I attempt to address some of the complaints in this thread, and took some liberties with my approach: https://review.source.android.com/#change,16690
Aug 26, 2010
Issue 693 has been merged into this issue.
Dec 15, 2010
(No comment was entered for this change.)
Status:
Released
|
||||||||||
| ► Sign in to add a comment | |||||||||||