978850 - Can we make a type of flag that doesn't send email on setting/unsetting?

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[cmtalbert]

Nowadays on the Mozilla project, there are a lot of flags being set (mostly through the whiteboard) for various types of project tracking so that things can be more easily queried later. Many times, though setting these flags amounts to "I or someone will look at this later via the query" or "I am marking this as something we don't need to look at via a query" and in cases like this, it would be helpful if bugzilla *didn't* send email on these changes.

I can think of lots of ways to do this - 
* create a flag type called "ignorable" that is called out in the mail preferences so that you can optionally receive or ignore mail from that particular class of flags
* Create another checkbox on the showbugs page that says "don't email if I change this flag"
* Some other idea....

What is the feasibility of adding this to BMO? Are there ways to do this easily?

Comment 1

[(no longer active)]

FWIW, the context here is that the QA team uses the status whiteboard flag to add tokens such as [qa-] to say that this bug doesn't require QA attention.  There is already the tags mechanism for tagging bugs with arbitrary strings which will only be visible to your user account, and that doesn't send out bugmail.  But this is a flag which needs to be shared across everyone on the QA team, which is why tags cannot be used here.

I think a solution specific to [qa-/+] is sufficient here, no need to create a generic solution.  Clint, please correct me if I'm wrong.

Comment 2

[David Lawrence [:dkl]]

Well we can certainly add code our extensions that will stop emails if the flag change was the only change for the bug. My concern is proper parsing of the whiteboard field and looking for specific strings. Seems error prone especially if there is other text or the user has made other whiteboard changes at the same time and want those changes to be sent out via email. I would rather this be a separate field somehow either using a custom field or even better creating a specific qa{?,+,-,X} flag that we can more easily look for in the extension code when determining whether to send the email.
The flag of course can be visible only to certain products/components if desired although we can do
similar with custom fields. Sound doable?

dkl

Comment 3

[cmtalbert]

I'm happy to have it as a separate field. Let me socialize this at the weekly QA meeting tomorrow and ensure that +/- is all the info needed. I believe there are also some triage whiteboard entries that are made that also probably shouldn't cause bugmail (i.e. a developer getting a mail when the bug shifts from UNCO to NEW is probably enough and the triage work to get to NEW is probably just distracting, so we should look at folding that in here too).

I'll report back after wednesday afternoon pacific's meeting. (1:30 PM Pacific, QA vidyo room if you want to come).

Leaving NI set so I remember to come back.

Comment 4

[:glob ✱]

(In reply to Clint Talbert ( :ctalbert ) from comment #3)
> I believe there are also some triage whiteboard entries that are made that
> also probably shouldn't cause bugmail (i.e. a developer getting a mail when
> the bug shifts from UNCO to NEW is probably enough and the triage work to
> get to NEW is probably just distracting, so we should look at folding that
> in here too).

if required, please file a separate bug for that.  it's a significantly different request from "create a field which doesn't trigger bugmail".  fwiw server-side filtering bugmail based on whiteboard changes is going to be painful and i would much rather explore alternatives before taking that route.

Comment 5

[Tracy Walker [:tracy]]

It seems to me the simplest fix is to add the whiteboard field to the email preferences list. Those that want don't want to see emails for whiteboard changes set their pref.  Those that want to see particular whiteboard changes will have to set the pref to send emails, then use their email filters to get rid of the "spam" they don't want to see.

Comment 6

[David Lawrence [:dkl]]

I could definitely see adding a new email preference for filtering whiteboard changes similar to how we do other fields currently. I could even see this being pushed upstream and would be willing to look at the amount of work that would be required (quick look doesn't look like too much).

glob, what are you're thoughts on the email preference to solve this task?

dkl

Comment 7

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #6)
> glob, what are you're thoughts on the email preference to solve this task?

the problem is the whiteboard field can, and is, used for anything.  i'm doubtful it would be useful to have an across-all-products "ignore any whiteboard changes" preference.

as the goal is to allow developers to opt out of project management changes, then adding a new field to track that state and allowing users to somehow opt out of receiving bugmail for changes made to that field makes more sense to me.

Comment 8

[Tracy Walker [:tracy]]

(In reply to Byron Jones ‹:glob› from comment #7)
> (In reply to David Lawrence [:dkl] from comment #6)
> > glob, what are you're thoughts on the email preference to solve this task?
> 
> the problem is the whiteboard field can, and is, used for anything.  i'm
> doubtful it would be useful to have an across-all-products "ignore any
> whiteboard changes" preference.

Yes, the whiteboard field is used in many ways. But from what I've seen, the majority of the whiteboard notes are there so users can create specific bugzilla queries around their note. I'd be curious to learn how many whiteboard notes are used for dynamic notification. My guess, not the majority.

Comment 9

[:glob ✱]

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #8)
> I'd be curious to learn how many whiteboard notes are used for dynamic notification.
> My guess, not the majority.

that's a very difficult question to answer correctly across all products which use bmo.

it's definitely used for more than just search hints by a few teams (including those working on firefox).  eg. australis priorities, the country on tech-evang bugs, referring to sumo kb articles.

i fear that a blanket "ignore all whiteboard changes" may result in relevant changes being missed, minimising its usefulness.

Comment 10

[David Lawrence [:dkl]]

(In reply to Byron Jones ‹:glob› from comment #9)
> (In reply to [:tracy] Tracy Walker - QA Mentor from comment #8)
> > I'd be curious to learn how many whiteboard notes are used for dynamic notification.
> > My guess, not the majority.
> 
> that's a very difficult question to answer correctly across all products
> which use bmo.
> 
> it's definitely used for more than just search hints by a few teams
> (including those working on firefox).  eg. australis priorities, the country
> on tech-evang bugs, referring to sumo kb articles.
> 
> i fear that a blanket "ignore all whiteboard changes" may result in relevant
> changes being missed, minimising its usefulness.

After non properly considering that before, I agree with glob that we need a separate field as it would not be as trivial of a change if we needed to allow users to configure on what type of changes to the whiteboard they want to see and which ones they do not. Have a separate specific field for purposes outlined in this bug would be much simpler to implement.

dkl

Comment 11

[(no longer active)]

(In reply to comment #8)
> (In reply to Byron Jones â¹:glob⺠from comment #7)
> > (In reply to David Lawrence [:dkl] from comment #6)
> > > glob, what are you're thoughts on the email preference to solve this task?
> > 
> > the problem is the whiteboard field can, and is, used for anything.  i'm
> > doubtful it would be useful to have an across-all-products "ignore any
> > whiteboard changes" preference.
> 
> Yes, the whiteboard field is used in many ways. But from what I've seen, the
> majority of the whiteboard notes are there so users can create specific
> bugzilla queries around their note. I'd be curious to learn how many whiteboard
> notes are used for dynamic notification. My guess, not the majority.

The issue here is not the generic use of whiteboard field that many people do.  It's *specifically* about people going through bugzilla and adding [qa-] to the whiteboard.  I watch around 20 bugzilla components, and at least throughout those components, [qa-] is _the only_ tag in the whiteboard field which is being set in this way across a large group of bugs, which is why you hear people complaining about it.

Comment 12

[David Lawrence [:dkl]]

After talking to glob some more about this, we have come to the decision to just add a new custom text input field (yet to be named). And then update our current extension code to add a user preference to filter their email based on if they want to see notifications about changes to the field. This will be visible in the email preferences similar to Component Watching, etc. We could call the new field 'QA Whiteboard' or something else if you like.

I would like to work on this and hope to be able to start next week.

dkl

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

That sounds like a good plan to me -- if we can use it for triaging and QA both I would use it!

Comment 14

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #12)
> After talking to glob some more about this, we have come to the decision to
> just add a new custom text input field (yet to be named).

+1

> And then update our current extension code to add a user preference to
> filter their email based on if they want to see notifications about
> changes to the field.

i'm actually not a fan of adding another field to the email notification preferences screen; sorry if i didn't communicate that well enough earlier.  i'm concerned we'll be adding more noise to an already complicated screen, and it opens the door for further requests for field-specific filtering which will only compound this issue further.

i think we'd be better served by adding the ability for users to filter based on arbitrary fields.
ie. build up a list of conditions which, when met, cause the bugmail to be not sent.
as i think we don't need to support filtering on field values, this can be processed on the jobqueue servers instead of blocking bug updates.

i don't think it needs to be complicated either:

  don't send me bugmail where any of the following conditions are met:
  product: [__any__] component: [__any__] changed-field: [qa_whiteboard]
  product: [firefox] component: [__any__] changed-field: [assignee]
  ..

Comment 15

[cmtalbert]

(In reply to Byron Jones ‹:glob› from comment #14)
> (In reply to David Lawrence [:dkl] from comment #12)
> > After talking to glob some more about this, we have come to the decision to
> > just add a new custom text input field (yet to be named).
> 
> +1
> 
> > And then update our current extension code to add a user preference to
> > filter their email based on if they want to see notifications about
> > changes to the field.
> 
> i'm actually not a fan of adding another field to the email notification
> preferences screen; sorry if i didn't communicate that well enough earlier. 
> i'm concerned we'll be adding more noise to an already complicated screen,
> and it opens the door for further requests for field-specific filtering
> which will only compound this issue further.
> 
> i think we'd be better served by adding the ability for users to filter
> based on arbitrary fields.
> ie. build up a list of conditions which, when met, cause the bugmail to be
> not sent.
> as i think we don't need to support filtering on field values, this can be
> processed on the jobqueue servers instead of blocking bug updates.
> 
> i don't think it needs to be complicated either:
> 
>   don't send me bugmail where any of the following conditions are met:
>   product: [__any__] component: [__any__] changed-field: [qa_whiteboard]
>   product: [firefox] component: [__any__] changed-field: [assignee]
>   ..
Glob, from the discussion at the QA meeting (which I forgot to come back here afterward, sorry) this would solve both QA's concerns (sometimes people do take action on QA- and find the email from that change useful). But, having a specific field for QA and triage would be helpful as well as being able to specifically not get email based on these criterions above.

Thanks a bunch glob & dkl.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

One thing that came up in QA meetings that I think is missing from this discussion: While some developers might not care that their bug fix is not going to get QA verification, others might. Marking a bug [qa-] is an opportunity for developers and people cc-ed on a bug to see that QA has de-prioritized their bug verification.  Devs can then say, No, actually we'd like this verified.  Maybe that doesn't actually happen enough to be significant.      

The other issues we brought up were that, the spate of [qa-] and other bugmail shows that we are tackling a backlog and maybe even catching up.  Couldn't people make bugmail filters to ignore mail with [qa-], without having to a special field that doesn't send bugmail? Is this really such a big deal?  We all get a lot of bugmail!

Comment 17

[(no longer active)]

(In reply to comment #16)
> One thing that came up in QA meetings that I think is missing from this
> discussion: While some developers might not care that their bug fix is not
> going to get QA verification, others might. Marking a bug [qa-] is an
> opportunity for developers and people cc-ed on a bug to see that QA has
> de-prioritized their bug verification.  Devs can then say, No, actually we'd
> like this verified.  Maybe that doesn't actually happen enough to be
> significant.      

Without intending to get into the higher level discussion here, developers generally don't assume that QA is going to do any work on their bugs at all.  That is why flags such as qawanted or regressionrage-wanted exist.

> The other issues we brought up were that, the spate of [qa-] and other bugmail
> shows that we are tackling a backlog and maybe even catching up.  Couldn't
> people make bugmail filters to ignore mail with [qa-], without having to a
> special field that doesn't send bugmail?

How does one do that without missing the changes made to the other parts of the status whiteboard?  The problem is that [qa-] annotations are part of a larger status whiteboard field which is basically free form text.  It's difficult to filter things out here.

> Is this really such a big deal?  We
> all get a lot of bugmail!

The number of bugmail that people receive is vastly different.  As I mentioned in comment 11 for example, I for example watch around 20 different components in Bugzilla, and sometimes I spend a significant amount of time going through a mass number of these notifications.

Please note that I'm not trying to argue that this flag is not important, I'm just asking for a way to opt out of receiving notifications about this because it takes a significant amount of time on my behalf to deal with it.  :-)

Comment 18

[:glob ✱]

ok, looks like the plan is to do both:

1. create a new cf_qa_whiteboard field
   - single line text field (varchar(255))

2. add the ability to filter bugmail server-side
   - simple controls - product / component / changed-field


clint: can you please provide a list of all the products that should show this field?  once we have that we can add the field and you will be able to start using it right away.

Comment 19

[cmtalbert]

I think the list is:
Firefox OS
Core
Firefox
Fennec
Toolkit

NI' Juanb, Jsmith, and Kbrosnan to verify that I have that right.

Rbillings and Edwong, for web/marketplace and services areas do y'all use the QA triage flags? If so you might respond with the proper list of products where you'd want this field to appear.

Comment 20

[Kevin Brosnan [Ex-Mozilla]]

Fennec is inconsistent when it comes to using QA flags. I would be more inclined to use them as a flag instead of a whiteboard.

Comment 21

[Jason Smith [:jsmith]]

FxOS - we don't really make use of the qa-/qa+/qa? flags, but we do make use of other whiteboard flags that we're the only consumers of (test run whiteboards & QARegressExclude). As such, I can see value in introducing this QA whiteboard into the FxOS product, although it's likely going to be used for a different use case than the qa-/qa+/qa? use case.

Comment 22

[:glob ✱]

the field is now visible on the following products:
- firefox os
- core
- firefox
- toolkit

(implementation note: currently using bugzilla's built in cf visibility controls.  we should switch to bmo's custom handling of this as part of the development work here).

Comment 23

[Rebecca Billings [:rbillings]]

For the majority of web projects we only use [qa-] when needed. It's not used often enough to generate large amounts of extra email [speaking only for myself]. I can't think of a specific product that would need this field, but I wouldn't object to having it added in general.

Comment 24

[Edwin Wong [:edwong]]

We don't enforce usage of the qa<operator> flag.  For now, no need to add any specific products to the list.

Comment 25

[juan becerra [:juanb]]

Core, Firefox Toolkit, and if Mozilla Services (Firefox Sync) is ok with no additional changes, then we're set from desktop side.

Comment 26

[:glob ✱]

i have created a separate bug to track the work of implementing server-side bugmail filtering: bug 990980.