Bug 891251 - Assignee missing in emails
Assignee missing in emails
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Email Notifications (Show other bugs)
4.2
Unspecified Unspecified
unspecified Severity high (vote)
: ---
: ---
Assigned To: Simon Green
tools-bugs
: Reopened
Depends On:
Blocks: 918471
  Show dependency treegraph
 
Reported: 2013-01-02 05:34 EST by Marcela Mašláňová
Modified: 2014-10-12 18:49 EDT (History)
5 users (show)

See Also:
Fixed In Version: 4.2.5-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-14 18:13:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Marcela Mašláňová 2013-01-02 05:34:44 EST
Description of problem:
Last few weeks are new bugs sent without information about asignee. Please, add it back. People, who are CC'ed on many other users, can't say if the bug is theirs or someone else.

Version-Release number of selected component (if applicable):
4.2.4-7
Comment 1 Simon Green 2013-01-04 05:22:04 EST
This field was removed (along with many others) because in the majority of newly filed bugs, the assignee is the default assignee of the component.

If you are the assignee of the bug, it will appear at the bottom of the e-mail, in the 'You are receiving this mail because:' section. This information is also in the e-mail headers. I consider this sufficient.

  -- simon
Comment 2 Marcela Mašláňová 2013-01-07 08:35:27 EST
I have at least two use-cases for the asignee field.

1/ I'm manager of a team and I'm CCed to their bugs. Now I can't say who is responsible for which bug without opening the bug in bugzilla. My daily bugzilla spam is more than 200 emails, so it's lot of looking.

2/ I am member of Perl SIG. It's hard to say from the name of component, which packages belong to who. I need to see who is a maintainer, because I fix only packages of some people and I tend to not touch bugs of other people.

With my use-cases is bugzilla email less useful than before. If you want to save space in emails, then you can remove priority and severity fields, which are useless if you read whole email.
Comment 4 Petr Pisar 2013-01-08 05:08:41 EST
I'd like to demonstrate how current notifications are burdening. Here is notification I've just received:

Date: Tue, 08 Jan 2013 08:47:04 +0000
From: bugzilla@redhat.com
To: perl-devel@lists.fedoraproject.org
Subject: [Bug 892914] New: perl-Compress-Raw-Bzip2-2.060 is available

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=892914

            Bug ID: 892914
           Summary: perl-Compress-Raw-Bzip2-2.060 is available
           Product: Fedora
           Version: rawhide
         Component: perl-Compress-Raw-Bzip2
          Keywords: FutureFeature, Triaged
          Severity: unspecified
          Priority: unspecified
          Reporter: upstream-release-monitoring@fedoraproject.org

Latest upstream release: 2.060
Current version in Fedora Rawhide: 2.059
URL: http://search.cpan.org/dist/Compress-Raw-Bzip2/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6R65gDPyNh&a=cc_unsubscribe


Let's examine the content:

(1) Bug ID is already in the in the e-mail subject. Remove it.
(2) Summary is already in the e-mail subject. Remove it.
(3) Product is already declared 5 lines above just before URL. Remove it.
(4) Version is first unique information. Ok.
(5) Component is useful because users usually do not mention component in bug summary. Ok.
(6) Keywords are new information. Ok.
(7) Severity is unspecified. Remove it.
(8) Priority is unspecified. Remove it.
(8) Reporter is new information. (Although I'm not sure this is so important it has to be delivered by e-mail.) Ok.

If you removed the undefined or redundant fields, the notification e-mail would get shorter and thus easier for humans to read and understand.
Comment 6 Simon Green 2013-02-05 19:39:50 EST
(In reply to comment #4)
> I'd like to demonstrate how current notifications are burdening. Here is
> notification I've just received:

The problem is different people have different requirements. As an example in the original bug, it was requested that we remove Assignee.

> (1) Bug ID is already in the in the e-mail subject. Remove it.

It is clickable link here (for those with HTML e-mail). It isn't a clickable link in the subject of the e-mail. Therefore it should stay.

> (3) Product is already declared 5 lines above just before URL. Remove it.

The product is being removed from the 5 lines above (with the release of Bugzilla 4.4-3), and therefore should stay here.

> (7) Severity is unspecified. Remove it.
> (8) Priority is unspecified. Remove it.

But when it is specified some people need to know what it is.

> (8) Reporter is new information. (Although I'm not sure this is so important
> it has to be delivered by e-mail.) Ok.

Some teams may consider this important. For me, there are certain people's whose bugs U will get more attention than from than other people.

> If you removed the undefined or redundant fields, the notification e-mail
> would get shorter and thus easier for humans to read and understand.

It isn't an easy art getting things perfect for most people.
Comment 8 Petr Pisar 2013-02-06 03:58:57 EST
(In reply to comment #6)
> (In reply to comment #4)
> > I'd like to demonstrate how current notifications are burdening. Here is
> > notification I've just received:
> 
> The problem is different people have different requirements. As an example
> in the original bug, it was requested that we remove Assignee.
>
I know, per-user configuration would be the best.
 
> > (1) Bug ID is already in the in the e-mail subject. Remove it.
> 
> It is clickable link here (for those with HTML e-mail). It isn't a clickable
> link in the subject of the e-mail. Therefore it should stay.
>
What? The URL is quoted two lines above. Who does need two identical URLs?
 
> > (7) Severity is unspecified. Remove it.
> > (8) Priority is unspecified. Remove it.
> 
> But when it is specified some people need to know what it is.
>
I did not said remove it always. I said remove it if the value is unspecified.
Comment 9 Simon Green 2013-02-07 00:05:15 EST
(In reply to comment #8)
> I know, per-user configuration would be the best.

File a bug for it.
  
> > > (1) Bug ID is already in the in the e-mail subject. Remove it.
> What? The URL is quoted two lines above. Who does need two identical URLs?

The URL is not two lines above for HTML e-mails. For text based e-mails the second bug id is not a clickable link.
 
> > > (7) Severity is unspecified. Remove it.
> > > (8) Priority is unspecified. Remove it.
> I did not said remove it always. I said remove it if the value is
> unspecified.

Still subjective. If you want that, file a separate bugs. This bug is about readding the assignee, qa contact, docs contact and cc list to the new e-mails only.

  -- simon
Comment 19 Simon Green 2013-03-14 18:13:46 EDT
This change is now live.

  -- simon

Note You need to log in before you can comment on or make changes to this bug.