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
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
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.
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 To: perl-devel.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 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.
(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.
(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.
(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
This change is now live. -- simon