Bug 417290 - The "The bug is resolved or reopened" email pref should also include newly created bugs
Frédéric Buclin
to also include newly created bugs, and rename the pref as "The bug is
created, resolved or reopened".
Would the majority of you using this email pref agree with this change?
The reason to change it is that we currently have no way to get bugmail
when a bug is created and resolved only (reopened can be seen as a 2nd
life to the bug), and I think both steps are related (status change,
start and end of the bug life). Related enough to be enclosed in the
same email pref IMO.
I know mkanat disagrees with this change (his reason given on IRC didn't
convince me; maybe he wants to re-explain it here once more), but I
would like more opinions on it.
LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps...@lists.mozilla.org>
Benton, Kevin
> email pref
> to also include newly created bugs, and rename the pref as
> "The bug is
> created, resolved or reopened".
>
> Would the majority of you using this email pref agree with
> this change?
Frankly, I think we ought to be able to specify email notifications on
change by status so that the entire list of possible status changes
appears. For example, verification engineers might care about all email
until VERIFIED, but most developers won't care about status beyond
RESOLVED. With custom workflow, this will become increasingly important
because users may want to know when state changes to DEFERRED for
example, but not care much as long as things continue to progress. It
all depends on the role of the "watcher".
Notify me when a bug I have a role in:
As Reporter | As Assignee | As CC | As QA Contact |
Becomes | Stays | Becomes | Stays | Becomes | Stays | Becomes | Stays |
Status
O | O | O | O | O | O | O | O |
Newly Created
O | O | O | O | O | O | O | O |
UNCONFIRMED
O | O | O | O | O | O | O | O |
NEW
O | O | O | O | O | O | O | O |
REOPENED
O | O | O | O | O | O | O | O |
DEFERRED
O | O | O | O | O | O | O | O |
ASSIGNED
O | O | O | O | O | O | O | O |
RESOLVED
O | O | O | O | O | O | O | O |
VDEFERRED
O | O | O | O | O | O | O | O |
VERIFIED
O | O | O | O | O | O | O | O |
CLOSED
Kevin
Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO 80528
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information. Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices. This
communication is for the intended recipient(s) only. If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.
Marc Schumann
> Frankly, I think we ought to be able to specify email notifications on
> change by status so that the entire list of possible status changes
> appears. For example, verification engineers might care about all email
I'm with Kevin. Plus, it should be product-wise. Let's have the status
transition matrix as e-mail prefs:
I want to receive an e-mail when the status changes
to UNCO NEW ASSI
from
UNCO
NEW
ASSI
... with each cell letting me specify bug roles.
Marc
Frédéric Buclin
> transition matrix as e-mail prefs:
Do you realize how many checkboxes this would involve? Times the number
of product if you want it per-product.
Why is status transition so important compared to other bug fields? What
if I'm only interested in bugs marked blocker or critical, or with
priority P1 and P2 only, etc...? This looks insane to me.
Maybe should you let your email client tag and filter incoming bugmails
rather than making the email prefs UI overcomplicated.
In my proposed patch, I'm only talking about open vs closed bugs, not
each step between.
LpSolit
Benton, Kevin
> the status
> > transition matrix as e-mail prefs:
>
> Do you realize how many checkboxes this would involve? Times
> the number
> of product if you want it per-product.
Yes, that's why I didn't suggest notifications by product, priority,
severity, or other. It is also why I didn't suggest doing notifications
by query filter either.
> Why is status transition so important compared to other bug
> fields? What
> if I'm only interested in bugs marked blocker or critical, or with
> priority P1 and P2 only, etc...? This looks insane to me.
>
> Maybe should you let your email client tag and filter
> incoming bugmails
> rather than making the email prefs UI overcomplicated.
>
> In my proposed patch, I'm only talking about open vs closed bugs, not
> each step between.
I think your patch is cool, though I think a nice incremental "next
step" will allow users to specify a finer granularity than open versus
closed especially for those sites that use QA contacts actively and have
implemented other status transitions. You'll note that I did not
utilize the full matrix of status transitions as Marc suggested :-)
I agree that overly complex notification schemes will only slow things
down for everyone and decrease usability. OTOH, what I do see is real
value in being able to help users reduce incoming mail before they get
it rather than forcing them to create rules to process what they would
see as "junk".
From a practical perspective, triagers don't care much about bugs after
triage. Developers don't care about bugs except when a bug has been
triaged and is assigned to them (or they're on the CC list). QA
contacts care about bugs from post-triage until verification has been
completed. Program managers care about bugs throughout the entire
lifecycle.
I think you can see why I responded the way I did. As I said above, I
think that this type of matrix can be a very nice incremental next step.
:-) Of course it will mean more coding to be done from the UI and the
back-end to implement.
I'll go ahead and file an enhancement request for this capability.
Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO 80528
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information. Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices. This
communication is for the intended recipient(s) only. If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.
Marc Schumann
> Do you realize how many checkboxes this would involve? Times the number
> of product if you want it per-product.
it's a lot of boxes. Drop-downs, even, if we put roles there.
But as it is, I'm a QS person in one product, so I'm interested in new
bugs, in status changes to RESOLVED, to FEEDBACK_CUSTOMER, to VERIFIED
and to CLOSED. In another product, I'm a QS person as well, but the
workflow is different, and I'm interested in status changes to
RESOLVED only. In most products, I'm interested in almost anything
about bugs I report, but for one product, where I file bugs for
others.
I'm really, really willing to go through UI hell to get this.
Marc
Benton, Kevin
> change by status so that the entire list of possible status changes
> appears. For example, verification engineers might care
> about all email
> RESOLVED. With custom workflow, this will become
> increasingly important
> because users may want to know when state changes to DEFERRED for
> example, but not care much as long as things continue to progress. It
> all depends on the role of the "watcher".
...
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=418301 as promised
:-)
Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO 80528
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information. Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices. This
communication is for the intended recipient(s) only. If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.
Max Kanat-Alexander
wrote:
> The reason to change it is that we currently have no way to
> get bugmail when a bug is created
Then add a preference "the bug is created".
This is like saying, "I have no way to drive to the store, so
I'm going to turn my cat into a car."
> I know mkanat disagrees with this change (his reason given on IRC
> didn't convince me; maybe he wants to re-explain it here once more),
> but I would like more opinions on it.
"The bug is resolved or reopened" means "the bug is closed, or
stops being closed."
"The bug is created" means "the bug is created".
They aren't related actions.
For example, imagine a company where managers want to know
where a bug is resolved, but they don't want to know when a bug is
filed, because there could be hundreds of bugs filed per day and they
don't care about them unless they're confirmed. (For example, I write
release notes, so I have exactly this sort of preference.)
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Max Kanat-Alexander
<kevin....@amd.com> wrote:
> Frankly, I think we ought to be able to specify email notifications on
Although we as advanced Bugzilla users may want that, the UI
complexity would be totally overwhelming to the average user. It would
also be a lot of implementation for not enough value.
Instead we should look into specific real-world use cases and
see how best to accommodate them.
Frédéric Buclin
> I'm going to turn my cat into a car."
Example completely unrelated.
> For example, imagine a company where managers want to know
> where a bug is resolved, but they don't want to know when a bug is
> filed, because there could be hundreds of bugs filed per day and they
> don't care about them unless they're confirmed.
But as a core developer/triager, I want to know when bugs are both
created (to triage them) and resolved (to know what has been fixed (core
developer) or incorrectly closed or reopened (triager)).
I can implement it as a separate email pref if you *really* want to.
LpSolit
Max Kanat-Alexander
wrote:
> But as it is, I'm a QS person in one product, so I'm interested in new
> bugs, in status changes to RESOLVED, to FEEDBACK_CUSTOMER, to VERIFIED
> and to CLOSED. In another product, I'm a QS person as well, but the
> workflow is different, and I'm interested in status changes to
> RESOLVED only. In most products, I'm interested in almost anything
> about bugs I report, but for one product, where I file bugs for
> others.
The correct solution to this problem is:
1) https://bugzilla.mozilla.org/show_bug.cgi?id=278455
2) The ability to "AND" together such criteria.
Then, for example, you could say:
"QA Contact" is "%user%" AND "Product" is "blah" AND "Status"
is "RESOLVED".
That would be ultimately flexible for very little UI complexity.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Max Kanat-Alexander
wrote:
> But as a core developer/triager, I want to know when bugs are both
> created (to triage them) and resolved (to know what has been fixed
> (core developer) or incorrectly closed or reopened (triager)).
>
> I can implement it as a separate email pref if you *really* want to.
Yes, a separate pref would still allow you to do what you
want, and would be more flexible. Also the way the code works now for
new bugs, I think it would probably be easier to make it a separate pref
anyhow.
Benton, Kevin
> On Mon, 18 Feb 2008 23:26:29 +0100 Frédéric Buclin <lps...@gmail.com>
> wrote:
>> But as a core developer/triager, I want to know when bugs are both
>> created (to triage them) and resolved (to know what has been fixed
>> (core developer) or incorrectly closed or reopened (triager)).
>>
>> I can implement it as a separate email pref if you *really* want to.
>
> Yes, a separate pref would still allow you to do what you
> want, and would be more flexible. Also the way the code works now for
> new bugs, I think it would probably be easier to make it a
> separate pref
> anyhow.
For the list - I responded in bug 278455 in favor of bug 418301 (still there as a point of reference):
Max,
Re: bug 418301 - I agree that this solution *could* work if it included the
ability to do both all base logic types (AND, OR, XOR, and NOT). The problem I
see with this is when a notification list is very long, it can take a
significant amount of time to send emails. That means a user must "hang in
there" longer for the "bug updated" message.
A challenge I see in light of this bug (278455) is usability - how does one
display the logic tree and how does one tell the system to send email when a
value changes to or from another value versus when a value remains in a given
state... I must assume that allowing users to do this would have to be a
configuration parameter as large installations would probably want to turn this
off or keep the number of allowable limitations per-user to a reasonable
minimum.
I also (wondering out loud) am considering - "How do I tell users how to
utilize this method versus the method I proposed in bug 418301?" because it
seems that this method will require users to be more Bugzilla-savvy. That's
not a bad thing, it just seems that the learning curve will be steeper.
Kevin
Kevin Benton
MySQL DBA #5739
Senior Software Developer
CAD Global Infrastructure Flow Services
Advanced Micro Devices
2950 E Harmony Rd
Fort Collins, CO 80528
The opinions stated in this communication do not necessarily reflect
the view of Advanced Micro Devices and have not been reviewed by
management. This communication may contain sensitive and/or
confidential and/or proprietary information. Distribution of such
information is strictly prohibited without prior consent of Advanced
Micro Devices. This communication is for the intended recipient(s)
only. If you have received this communication in error, please notify
the sender, then destroy any remaining copies of this communication.
-
Max Kanat-Alexander
<kevin....@amd.com> wrote:
> For the list - I responded in bug 278455 in favor of bug 418301
> (still there as a point of reference):
My answer is in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=278455#c11
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.