Bug 823694 - excessive pointless fields emailed.
excessive pointless fields emailed.
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Email Notifications (Show other bugs)
4.2
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Simon Green
tools-bugs
: Reopened
: 826087 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 18:11 EDT by Dave Jones
Modified: 2015-01-04 17:31 EST (History)
6 users (show)

See Also:
Fixed In Version: 4.2.4-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-21 00:52:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Jones 2012-05-21 18:11:09 EDT
the email notifications for newly created bugs now include a bunch of fields that isn't particularly useful, and just clutters up the email.

* "Bug ID" is extraneous (it's in the subject, and the url).

* Assignee / QA Contact rarely changes for a component and is uninteresting to get by mail every time (unless set to a non-default)

* Severity : Useless as long as its user-settable. Everyone thinks their bug is important.

* Whiteboard: abrt hashes aren't particularly interesting.

* Priority (See Severity)

* Regression: Story points:, Type:, Documentation:, Mount Type: are all useless in email (unless they're actually set to something) Suppress '---'  (I'd never even seen half of these before, despite having looked through thousands of bugs over the years!)

* Product: Fedora and Classification: Fedora are sort of pointless. (Especially when most (all?) filter on the X-Bugzilla-Product: header anyway. The same could also be said for 'Version:'

* Emailing "Status: NEW" is pointless. I know it's new, it says so in the Subject.

* OS: If it's filed against Fedora, we sort of know what OS it is. :-)


I suspect there might be reasons for some of these that I might have overlooked, but some of the above might need some reconsideration to reduce the amount of uninteresting info in bugs-by-mail.
Comment 1 Simon Green 2012-05-30 18:51:28 EDT
*** Bug 826087 has been marked as a duplicate of this bug. ***
Comment 2 Simon Green 2012-08-13 23:57:01 EDT
I agree. The excess fields were a result of the change to Bugzilla 4.2. I'll put out a call to see what fields should be dropped.

  -- simon
Comment 3 Simon Green 2012-08-30 21:29:33 EDT
E-mail sent to bugzilla-development-list:

Currently up to 56 fields are e-mailed when creating a new bug. This has
been made more of a problem since we introduced HTML e-mails (for those
who choose to receive HTML e-mails)

Here are the fields that we e-mail, in order:

+-------------------------+-------------------+
| name                    | description       |
+-------------------------+-------------------+
| bug_id                  | Bug #             |
| short_desc              | Summary           |
| product                 | Product           |
| version                 | Version           |
| rep_platform            | Platform          |
| bug_file_loc            | URL               |
| op_sys                  | OS/Version        |
| bug_status              | Status            |
| status_whiteboard       | Status Whiteboard |
| keywords                | Keywords          |
| bug_severity            | Severity          |
| priority                | Priority          |
| component               | Component         |
| assigned_to             | AssignedTo        |
| reporter                | ReportedBy        |
| qa_contact              | QAContact         |
| cc                      | CC                |
| dependson               | Depends on        |
| blocked                 | Blocks            |
| bug_group               | Group             |
| estimated_time          | Estimated Hours   |
| cf_issuetracker         | Issue Trackers    |
| external_bugzilla.url   | External Bug URL  |
| deadline                | Deadline          |
| classification          | Classification    |
| cf_build_id             | Build ID          |
| cf_story_points         | Story Points      |
| cf_partner              | Partner           |
| cf_clone_of             | Clone Of          |
| cf_environment          | Environment       |
| cf_type                 | Type              | *
| cf_regression_status    | Regression        |
| cf_mount_type           | Mount Type        |
| cf_documentation_action | Documentation     |
| cf_crm                  | CRM               |
| cf_layered_products     | Layered Product   |
+-------------------------+-------------------+

I am proposing that we change the list to:
+-------------------------+-------------------+
| name                    | description       |
+-------------------------+-------------------+
| bug_id                  | Bug #             |
| short_desc              | Summary           |
| product                 | Product           |
| version                 | Version           |
| component               | Component         |
| keywords                | Keywords          |
| bug_severity            | Severity          |
| priority                | Priority          |
| bug_group               | Group             |
| reporter                | ReportedBy        |
| dependson               | Depends on        |
| blocked                 | Blocks            |
| external_bugzilla.url   | External Bug URL  |
| cf_type                 | Type              | *
+-------------------------+-------------------+

None of the above changes affect what headers are sent with the e-mail.

Does anyone have any objections to the shorter list?
Comment 5 Simon Green 2012-09-10 21:15:44 EDT
Since noone raised any objections, list will be:

+-------------------------+-------------------+
| name                    | description       |
+-------------------------+-------------------+
| bug_id                  | Bug #             |
| short_desc              | Summary           |
| product                 | Product           |
| version                 | Version           |
| component               | Component         |
| keywords                | Keywords          |
| bug_severity            | Severity          |
| priority                | Priority          |
| reporter                | ReportedBy        |
| dependson               | Depends on        |
| blocked                 | Blocks            |
| bug_group               | Group             |
| external_bugzilla.url   | External Bug URL  |
| cf_type                 | Type              | *
|                         | Flags             |
+-------------------------+-------------------+
Comment 13 Dave Jones 2012-10-19 10:21:07 EDT
here's the mail I got for bug 868175 yesterday.
Almost every one of the points I made in comment #1 is still true.

            Bug ID: 868175
        QA Contact: extras-qa@fedoraproject.org
          Severity: unspecified
       	Whiteboard: abrt_hash:d5b5562ad8747424661e0a241cb641ddb149ae04
           Version: 17
          Priority: unspecified
               	CC: gansalmon@Gmail.com, itamar@ispbrasil.com.br,
                    jonathan@jonmasters.org, kernel-maint@redhat.com,
                    madhu.chinakonda@gmail.com
          Assignee: kernel-maint@redhat.com
           Summary: [abrt]: WARNING: at net/mac80211/driver-ops.h:12
                    ieee80211_do_stop+0x743/0x760 [mac80211]()
       	Regression: ---
      Story Points: ---
    Classification: Fedora
               	OS: Unspecified
          Reporter: vochomurka@gmail.com
              Type: ---
     Documentation: ---
          Hardware: x86_64
        Mount Type: ---
            Status: NEW
         Component: kernel
           Product: Fedora

In addition, we seem to have gained 'Mount type'. I have no idea what that even is.

I realise that some people might have value for some of the items on this list, but there still seems to be an awful lot of unnecessary information.
At the least, suppressing the '---' and unchanged default fields would cut down a lot.
Comment 14 Simon Green 2012-10-27 20:32:18 EDT
(In reply to comment #13)
> here's the mail I got for bug 868175 yesterday.
> Almost every one of the points I made in comment #1 is still true.

This bug has not gone live, which is why you are still seeing the fields you are.

  -- simon
Comment 18 Dave Jones 2012-11-21 00:12:13 EST
This is better, but still not right..  An example I just got..

Subject: [Bug 878687] New: [abrt]: BUG: unable to handle kernel NULL pointer dereference at           (null)

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

            Bug ID: 878687
           Summary: [abrt]: BUG: unable to handle kernel NULL pointer
                    dereference at           (null)
           Product: Fedora
           Version: 17
         Component: kernel
          Severity: unspecified
          Priority: unspecified
          Reporter: jries@salford-systems.com
              Type: ---



1. Product: Fedora is now appearing twice for some reason. (Given it's in the headers, not printing it at all would be nice, but at most, once will do)
2. Bug ID: is still duplicated information (already in the subject and url)
3. The unset severity/priority fields tell me nothing (most people seem to ignore them entirely, but some may have value for them if they are set)
4. The empty Type field is pointless.
Comment 19 Simon Green 2012-11-21 00:52:16 EST
(In reply to comment #18)
> 1. Product: Fedora is now appearing twice for some reason. (Given it's in
> the headers, not printing it at all would be nice, but at most, once will do)

The first one appears in all bugs (implemented in bug 838964). It doesn't take away the usefulness of showing the second one, especially for HTML formatted e-mails.

> 2. Bug ID: is still duplicated information (already in the subject and url)

As with the above, having the important information nicely formatted makes it easy to find the important information. I don't want to have to search the e-mail to find the information I want (e.g. part of a URL or the subject isn't the most useful)

> 3. The unset severity/priority fields tell me nothing (most people seem to
> ignore them entirely, but some may have value for them if they are set)

It is useful information to show. A bug marked as major / critical / the-roof-is-on-fire will receive more attention for some projects.

> 4. The empty Type field is pointless.

Fixed.

  -- simon
Comment 21 Dave Jones 2012-11-21 09:58:38 EST
(In reply to comment #19)
> (In reply to comment #18)
> > 1. Product: Fedora is now appearing twice for some reason. (Given it's in
> > the headers, not printing it at all would be nice, but at most, once will do)
> 
> The first one appears in all bugs (implemented in bug 838964). It doesn't
> take away the usefulness of showing the second one, especially for HTML
> formatted e-mails.

My read of that bug is that filtering is (as it always was) possible via X-Bugzilla-Product. I don't see why it was necessary to further clutter the already verbose text. This justification also doesn't address that it now appears _twice_ in that same body of text.



> > 3. The unset severity/priority fields tell me nothing (most people seem to> > > ignore them entirely, but some may have value for them if they are set)
> 
> It is useful information to show. A bug marked as major / critical /
> the-roof-is-on-fire will receive more attention for some projects.

I agree, some might. But when they are not set, sending an email telling me they aren't set seems pointless no ?
Comment 22 Simon Green 2012-11-21 14:52:55 EST
(In reply to comment #21)
> My read of that bug is that filtering is (as it always was) possible via
> X-Bugzilla-Product.

Debi was talking about human filtering, not machine filtering.

> I don't see why it was necessary to further clutter the
> already verbose text.

That is your opinion. As a PM for multiple projects myself, I tend to agree with Debi. It is useful to know straight away what the Product is. Having this in new e-mails means this human filtering is possible.

> This justification also doesn't address that it now
> appears _twice_ in that same body of text.

As per comment #19 and #20, having the important information nicely formatted makes it easy to find the important information. I don't want to have to search the e-mail to find the information I want

> > > 3. The unset severity/priority fields tell me nothing (most people seem to> > > ignore them entirely, but some may have value for them if they are set)
> > 
> > It is useful information to show. A bug marked as major / critical /
> > the-roof-is-on-fire will receive more attention for some projects.
> 
> I agree, some might. But when they are not set, sending an email telling me
> they aren't set seems pointless no ?

No.

  -- simon
Comment 23 Dave Jones 2012-11-21 15:21:28 EST
(In reply to comment #22)


> > This justification also doesn't address that it now
> > appears _twice_ in that same body of text.
> 
> As per comment #19 and #20, having the important information nicely
> formatted makes it easy to find the important information. I don't want to
> have to search the e-mail to find the information I want

Please explain how printing the exact same line of text within the 4 lines of other is 'nicely formatted' ? 

> > I agree, some might. But when they are not set, sending an email telling me
> > they aren't set seems pointless no ?
> No.

Because ?
Comment 24 Simon Green 2012-11-21 15:44:29 EST
(In reply to comment #23)
> Please explain how printing the exact same line of text within the 4 lines
> of other is 'nicely formatted' ? 

Nicely formatted refers to having all the information appear in the table (for HTML e-mail) or aligned (for text formatted e-mails). Having the important information nicely formatted makes it easier to find it. People don't want to have to search the e-mail to find the information I want.

> > > I agree, some might. But when they are not set, sending an email telling me
> > > they aren't set seems pointless no ?
> > No.
> 
> Because ?

It is useful information to show. A bug marked as major / critical / the-roof-is-on-fire will receive more attention for some projects.

  -- simon
Comment 25 Dave Jones 2012-11-21 15:56:38 EST
(In reply to comment #24)

> Nicely formatted refers to having all the information appear in the table
> (for HTML e-mail) or aligned (for text formatted e-mails).

What happens if people start requesting the same treatment for other fields because they don't have filters ?
Are you going to duplicate the same information twice for those fields too ?

I'll setup a script to sed them out myself. Hopefully this isn't the start of something I'll have to maintain over time.

>  Having the
> important information nicely formatted makes it easier to find it. People
> don't want to have to search the e-mail to find the information I want.

Perhaps long-term the email preferences tab of bugzilla could include which headers get emailed. Does that sound plausible ? Worth opening a bug for ?

> > > > I agree, some might. But when they are not set, sending an email telling me
> It is useful information to show. A bug marked as major / critical /
> the-roof-is-on-fire will receive more attention for some projects.

I feel like we're going in circles here. I'm not objecting to them being sent when they've been set to a value. My complaint was about 'unspecified' being unnecessary, just as '---' was for the Type field mentioned above.
Comment 26 Simon Green 2012-11-21 17:17:03 EST
(In reply to comment #25)
> What happens if people start requesting the same treatment for other fields
> because they don't have filters ?
> Are you going to duplicate the same information twice for those fields too ?

HSS PM consider all Bugzilla bugs. It would need to be a very convincing case to add extra fields to the e-mail. I fully understand why people (who look after multiple products) would want the Product field to be on all bugs.

> Perhaps long-term the email preferences tab of bugzilla could include which
> headers get emailed. Does that sound plausible ?

No.

> Worth opening a bug for ?

Probably not.

  -- simon

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