892615 - Add a 24 hour nag to all requests (review, feedback and need-info) and make them follow-able

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

We would like to encourage people to have quick turnarounds on reviews and this would encourage that. Also allowing the nags to be follow-able would allow managers to follow up, respond if the person is on PTO and suggest other reviews.

Comment 1

[Mark Côté [:mcote]]

Is this intended to nag *every* 24 hours, or just after the first 24 hours?  Just wondering because the code-review discussion seems to be settling on "reply within 24 hours to give an ETA", not "review within 24 hours".  Given that we don't yet have an ETA field, I'm not sure how useful it is to have something nagging you every day until the review is done.

Comment 2

[:glob ✱]

are you aware of the existing review nagging system, which sends nags for any request older than seven days?  see bug 682847

do you mean "one week day" rather than "24 hours"?  i wouldn't expect to receive multiple nags for a review placed last thing on friday.  hrm, even then, dealing with timezones may be tricky (but we should ignore public holidays!).

i suspect this should apply to firefox development related products only; other teams, especially community products which are tracked on bugzilla, would want to either disable this, or have different timings.  can you please provide a list of products where these review nags should be triggered using a 24 hour timer.

can you please explain what you mean by "follow-able"?

do you want requests to be nagged for any user, or should this be limited to employees only?  for example, needinfo is used a lot in triage to get more information from bug reporters, and i don't think it would be appropriate to nag them for a response (a third of needinfo requests on the system are of this form).

--

when the current nagging system was enabled, there was much chatter about how to disable those emails or filter them directly to the trash.  my response to those questions was "the way to disable is to either action the review, or reassign to someone who can".  however i hold concerns that a high volume nagging system will very quickly be similarly filtered.

--

if the crux of the issue is one of visibility of lagging reviews for managers, perhaps it would be better to instead create a report which clearly shows outstanding requests, which could be emailed to managers as well as visible on a bugzilla page.

it may also help to clearly indicate the age of a request on show_bug.  perhaps next to the flag, or in a summary box which clearly indicates that the bug is waiting for X, and has been waiting for N days.

Comment 3

[(dormant account)]

Byron,
There are 2 parts to this request.

1) Better tracking of review requests by default. We should setup the existing nag system to ping people once a day if they have reviews. 

If people choose to filter those or ignore these individual messages, that's their choice. 

It would be nice if the current review nag was cleaned up a bit:
* The message should  have a link in there so it's obvious how to turn that off.
* Show number of requests in subject
* Provide id of requester in the email
* Indicate if you have commented in the bug since request was made(this is the crux of the 24hour policy)
* Age of request sounds good

2) "instead create a report which clearly shows outstanding requests, which could be emailed to managers as well as visible on a bugzilla page."
This is also useful for requesters who are waiting on reviews from multiple people. This should include all of the info from 1). Having this in a report + email form would be great.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Byron Jones ‹:glob› from comment #2)
> are you aware of the existing review nagging system, which sends nags for
> any request older than seven days?  see bug 682847
Yes, as we've been discussing 7 days is too long.

> do you mean "one week day" rather than "24 hours"?  i wouldn't expect to
> receive multiple nags for a review placed last thing on friday.  hrm, even
> then, dealing with timezones may be tricky (but we should ignore public
> holidays!).
Ideally we could handle weekends well (i.e. not nag for a review requested on Friday until Monday). Timezones shouldn't matter, the clock should start ticking when the patch is posted (so, a request from NZ on Friday wouldn't nag a reviewer until Monday NZ time, which is Sunday for North America, and they've already had a full working day to get to at that point).

Holidays would seem to over complicate things. Great if we could handle them, but I can't imagine that effort being worth it.
> 
> i suspect this should apply to firefox development related products only;
> other teams, especially community products which are tracked on bugzilla,
> would want to either disable this, or have different timings.  can you
> please provide a list of products where these review nags should be
> triggered using a 24 hour timer.
<snip>
> 
> do you want requests to be nagged for any user, or should this be limited to
> employees only?  for example, needinfo is used a lot in triage to get more
> information from bug reporters, and i don't think it would be appropriate to
> nag them for a response (a third of needinfo requests on the system are of
> this form).
> 

I would assert that this should be the default for the project. It should also be customizable (i.e. turn-off-able) in the email preferences such that community members can opt out if they'd like.
 
> can you please explain what you mean by "follow-able"?
I suppose I mean "watch-able". You should be able to watch another user's nag mail. Ideally all managers/tech leads at mozilla should watch the nags for those that they are responsible for. Also, owners and peers should watch each other to be able to pick up the slack if one is off on vacation.

> --
> 
> when the current nagging system was enabled, there was much chatter about
> how to disable those emails or filter them directly to the trash.  my
> response to those questions was "the way to disable is to either action the
> review, or reassign to someone who can".  however i hold concerns that a
> high volume nagging system will very quickly be similarly filtered.
If people decide to ignore or filter these, that's their choice. A tool is only as useful as user makes it. But, as I said above it would probably be polite to put an opt out in email prefs.

> --
> 
> if the crux of the issue is one of visibility of lagging reviews for
> managers, perhaps it would be better to instead create a report which
> clearly shows outstanding requests, which could be emailed to managers as
> well as visible on a bugzilla page.
I don't think a report is what we want here. A report assumes that it will be checked frequently. We want to encourage a culture where reviews are done promptly. Therefore the sending of a nag mail *should* be exceptional. If the report showed useful information only exceptionally, I highly doubt it would be checked frequently enough to be effective.


> it may also help to clearly indicate the age of a request on show_bug. 
> perhaps next to the flag, or in a summary box which clearly indicates that
> the bug is waiting for X, and has been waiting for N days.

sounds good

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Mark Côté ( :mcote ) from comment #1)
> Is this intended to nag *every* 24 hours, or just after the first 24 hours? 
> Just wondering because the code-review discussion seems to be settling on
> "reply within 24 hours to give an ETA", not "review within 24 hours".  Given
> that we don't yet have an ETA field, I'm not sure how useful it is to have
> something nagging you every day until the review is done.

I would suggest every 24 hours since each day that passes the patch author looses more context and the patch gets more bit rotted.

That said, it would probably be useful to have a "turn off nags" check box (default off) on the patch details page so that if a reviewer comments in the bug "I'll get to this next week" they can save themselves from unneeded bugmail.

Comment 6

[Brad Lassey [:blassey] (use needinfo?)]

> do you want requests to be nagged for any user, or should this be limited to
> employees only?  for example, needinfo is used a lot in triage to get more
> information from bug reporters, and i don't think it would be appropriate to
> nag them for a response (a third of needinfo requests on the system are of
> this form).
you make a good point about need-info's though. perhaps need-info nags could be opt-in? I'm not sure what the right decision here is. I lumped them in here with review and feedback requests because often in triage we leave comments to the effect of "XXXX ping? for the need-info."

The problem we're really trying to solve is review and feedback requests, so I'm happy to defer the discussion about need-info so it doesn't derail things.

Comment 7

[David Teller [:Yoric] - still alive but not very active]

> That said, it would probably be useful to have a "turn off nags" check box (default off) on the patch details page so that if a reviewer comments in the bug "I'll get to this next week" they can save themselves from unneeded bugmail.

What about a "Bug me again in XXX days" instead of a "turn off nags"?

Comment 8

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to David Rajchenbach Teller [:Yoric] from comment #7)
> > That said, it would probably be useful to have a "turn off nags" check box (default off) on the patch details page so that if a reviewer comments in the bug "I'll get to this next week" they can save themselves from unneeded bugmail.
> 
> What about a "Bug me again in XXX days" instead of a "turn off nags"?

Event better

Comment 9

[:glob ✱]

thanks for the information.
here's a summary of changes required to the current system as i understand it:

- update the frequency of the nag
  - add the ability to customise the "nag after" time on a per-product basis
  - set the default for all firefox and related products to 24 hours
  - generate nags for review and feedback flags only
  - do not generate nags on the weekend (as per the receiver's timezone)
  - add the ability to opt-out of nag emails

- update the nag email
  - include the count of flags in the subject
  - include the requester
  - indicate if the recipient has commented on the bug since the request was made
  - include a link to clearly show how to opt-out

- add age indicators to flags ui on show_bug, attachment details, and "my requests"

- add the ability to receive nags for other users
  - include "you are receiving this email because .." in the content
  - ensure security of bugs is honoured
  ? send a nag for users watched in this way even if that user has opted-out

- add per-patch per-user nag delays
  - "remind me again in NNN days"

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Byron Jones ‹:glob› from comment #9)
>   ? send a nag for users watched in this way even if that user has opted-out
definitely on this

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Byron Jones ‹:glob› from comment #9)
>   - do not generate nags on the weekend (as per the receiver's timezone)
Do we know the receiver's timezone? It seems like you could (and it would be easier) to pick an arbitrary timezone in which the "clock" for a request didn't run for the weekend's 48 hours.

Comment 12

[David Lawrence [:dkl]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #11)
> (In reply to Byron Jones ‹:glob› from comment #9)
> >   - do not generate nags on the weekend (as per the receiver's timezone)
> Do we know the receiver's timezone? It seems like you could (and it would be
> easier) to pick an arbitrary timezone in which the "clock" for a request
> didn't run for the weekend's 48 hours.

Only if they have set one explicitly in their user preferences. Otherwise it defaults to the server's timezone (PDT). Currently only around 1800 people have set a custom timezone out of ~475k users.

dkl

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to David Lawrence [:dkl] from comment #12)
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #11)
> > (In reply to Byron Jones ‹:glob› from comment #9)
> > >   - do not generate nags on the weekend (as per the receiver's timezone)
> > Do we know the receiver's timezone? It seems like you could (and it would be
> > easier) to pick an arbitrary timezone in which the "clock" for a request
> > didn't run for the weekend's 48 hours.
> 
> Only if they have set one explicitly in their user preferences. Otherwise it
> defaults to the server's timezone (PDT). Currently only around 1800 people
> have set a custom timezone out of ~475k users.
> 
> dkl

That works as long as the logic is "don't count the weekend in the 24 hours" rather than "don't send the email on a Saturday or Sunday".

Comment 14

[:glob ✱]

for the first three items in comment 9, i should be able to do them within a week.

the other two items are more difficult, and may require longer.  if need be i'll split the work across multiple bugs to land the first three points first.

Comment 15

[:glob ✱]

unfortunately some other things came up, and i haven't had as much time as i'd expected to work on this, so it won't be ready for review this week as promised.

Comment 16

[(dormant account)]

Byron,
What's the status of this work?

Comment 17

[:glob ✱]

sorry about the lack of communication and delays here; this is something that i _have_ been working on.

due to the schema changes required the earliest we can get this is next week (we need to touch the profiles table during our downtime in bug 900375).

i expect to have a patch up review this week.

Comment 18

[:glob ✱]

Attachment: 892615_1.patch

- replaces the current RequestWhiner extension
- per product configuration of nagging frequency
  - defaults to 7 days to match request whiner
  - can be set to 0 to disable reminders for that product
- all review and feedback requests are included
- needinfo requests are only included if the requestee has editbugs
- adds user preference to allow requestee to opt-out

- reminder email's subject contains summary of flags
  - [Bugzilla] Your Outstanding Requests (14 review, 1 feedback, 1 needinfo)
- requester is included
- age of request in email is relative
  - "last week" / "several months ago" / ...
- includes links to opt-out

- adds ability to defer a reminder
- separate page, only linked from the reminder emails
- maximum of 7 days deferral

- adds ability to watch reminders for users
- single email with a report of all users watched
- includes users who opt-out
- no restrictions on who can watch, or on who you can watch
- includes an indicator if the requestee has deferred the reminder

things that didn't make the cut:
- requestee timezone sensitive nagging
  - we'll ask IT to schedule the cronjob for US weekdays only
- add age indicators to show_bug UI
  - wasn't able to get something that looked sane
- indicate if the recipient has commented on the bug since the request was made
  - if required will do in a later revision, didn't want to hold up the patch anymore

Comment 19

[(dormant account)]

glob, this sounds great!

Comment 20

[(dormant account)]

So it looks like bugzilla features to deal with review lag...are stuck due to review lag.

Comment 21

[Bob Moss :bmoss]

Dave, are we stuck on something here for getting the review done?

Comment 22

[Mark Côté [:mcote]]

It is his next highest priority; we were stuck on getting lots of work done for the front-end contractor recently.  My apologies; we'll work on getting the BMO guys' ridiculously large review queues cleaned out.

Comment 23

[David Lawrence [:dkl]]

Left out the user-error-errors.html.tmpl template in your last patch. Continuing review. 

t/012throwables.t .... 1/513 
#   Failed test './extensions/RequestNagger/Extension.pm has 4 error(s):
# user error tag 'request_nagging_flag_invalid' is used at line(s) (101,103,105) but not defined for language(s): any
# user error tag 'request_nagging_flag_set' is used at line(s) (111) but not defined for language(s): any
# user error tag 'request_nagging_flag_not_owned' is used at line(s) (115) but not defined for language(s): any
# user error tag 'request_nagging_flag_wind' is used at line(s) (113) but not defined for language(s): any'
#   at t/012throwables.t line 208.

#   Failed test 'extensions/RequestNagger/Extension.pm has 4 error(s):
# user error tag 'request_nagging_flag_invalid' is used at line(s) (101,103,105) but not defined for language(s): any
# user error tag 'request_nagging_flag_set' is used at line(s) (111) but not defined for language(s): any
# user error tag 'request_nagging_flag_not_owned' is used at line(s) (115) but not defined for language(s): any
# user error tag 'request_nagging_flag_wind' is used at line(s) (113) but not defined for language(s): any'
#   at t/012throwables.t line 208.
# Looks like you failed 2 tests of 513.
t/012throwables.t .... Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/513 subtests

Comment 24

[David Lawrence [:dkl]]

(In reply to Byron Jones ‹:glob› from comment #18)
> Created attachment 796734 [details] [diff] [review]
> 892615_1.patch
> 
> - replaces the current RequestWhiner extension

Should we then remove the RequestWhiner extension (or disable)?

dkl

Comment 25

[David Lawrence [:dkl]]

Comment on attachment 796734 [details] [diff] [review]
892615_1.patch

Review of attachment 796734 [details] [diff] [review]:
-----------------------------------------------------------------

For the most part looks good with a few comments. Some strange issue I ran across is that I could not get an email to deliver to me (Sendmail) if I 
have HTML as my email type. It would deliver to me normally if I select TEXT. This was of course after enabling email delivery for my account. I spent
quite a bit of time debugging and comparing the email generation code in send-request-nags.pl and Bugzilla::BugMail::_generate_email. When I do a normal
bug change or flag notification, the email is delivered properly using either HTML or TEXT. Also to add, if I choose Test as the mail_delivery_method,
everything shows up in data/mailer.testfile properly. My maillog log file shows the email being sent out as well which makes it more strange. Did you
have success with this test case when implementing it? I wonder if it is a strangeness with my environment. If it works for you then it would not hold
up review IMO.

dkl

::: extensions/RequestNagger/Extension.pm
@@ +199,5 @@
> +
> +        $dbh->bz_start_transaction();
> +
> +        # user preference
> +        # $input->{nag_enabled}

Remove and make the template show a link to the "General Preferences" tab highlighting the request_nagging_row.

::: extensions/RequestNagger/bin/send-request.nags.pl
@@ +153,5 @@
> +            attributes => { content_type => "text/plain" },
> +            body => $text,
> +        )
> +    );
> +    if (1 && $vars->{recipient}->setting('email_format') eq 'html') { # XXX

Whats going on here?

::: extensions/RequestNagger/lib/Constants.pm
@@ +15,5 @@
> +    REQUESTEE_NAG_SQL
> +    WATCHING_NAG_SQL
> +);
> +
> +# the order of this array determins the order used in email

s/determins/determines/

::: extensions/RequestNagger/template/en/default/account/prefs/request_nagging.html.tmpl
@@ +23,5 @@
> +  <option value="off" [% "selected" IF !user.settings.request_nagging.is_default
> +                                       && user.settings.request_nagging.value == "off" %]>
> +    Off
> +  </option>
> +</select>

Why is this a drop down if you cannot make a change from this page? Make it a readonly link to the "General Preferences" using the #request_nagging anchor.

::: extensions/RequestNagger/template/en/default/email/request_nagging-watching.html.tmpl
@@ +73,5 @@
> +                   [% request.bug.product FILTER html %] :: [% request.bug.component FILTER html %]">
> +            [% request.bug.id FILTER none %] - [% request.bug.short_desc FILTER html %]
> +          </a><br>
> +          <b>[%+ request.flag.age FILTER html %]</b> from [% request.requester.identity FILTER html %]<br>
> +          <br>

Lose the extra <br> here as it puts a gap between the requester identity and the deferred until line. This make the deferred until line display too close to the next flag below.

::: extensions/RequestNagger/template/en/default/pages/request_defer.html.tmpl
@@ +41,5 @@
> +  [% IF flag.attachment %]
> +    <div class="flag-attach">
> +      <div class="flag-attach-desc">
> +        <a href="">
> +          [% flag.attachment.description FILTER html %]

This should link to the details page for the attachment?

@@ +56,5 @@
> +      </div>
> +      [% IF flag.attachment.ispatch %]
> +        <div class="flag-attach-actions">
> +          <a href="">Diff</a> |
> +          <a href="">Review</a>

Need proper href values to link to the appropriate pages here. Also the font size for Diff|Review is too small.

@@ +97,5 @@
> +</form>
> +
> +[% IF flag.attachment %]
> +
> +[% END %]

Is this needed?

Comment 26

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #25)
> > +    if (1 && $vars->{recipient}->setting('email_format') eq 'html') { # XXX
> Whats going on here?

oops; that's some debugging code.

i had no problems with either text-only or html email delivery during development.

> Remove and make the template show a link to the "General Preferences" tab
> highlighting the request_nagging_row.
> ...
> Why is this a drop down if you cannot make a change from this page? Make it
> a readonly link to the "General Preferences" using the #request_nagging
> anchor.

it's a bug that the changes made here aren't saved.  i find it much clearer to keep all things relating to the reminders on the same tab, so i'll fix the saving instead of changing it to link to the preferences tab.


will address the other issues in the next revision.

Comment 27

[:glob ✱]

Attachment: 892615_2.patch

Comment 28

[David Lawrence [:dkl]]

Comment on attachment 819556 [details] [diff] [review]
892615_2.patch

Review of attachment 819556 [details] [diff] [review]:
-----------------------------------------------------------------

Issues can be fixed on checkin. r=dkl

::: extensions/RequestNagger/template/en/default/account/prefs/request_nagging.html.tmpl
@@ +46,5 @@
> +</p>
> +
> +<p>Add users to my watch list (comma separated list):
> +  [% INCLUDE global/userselect.html.tmpl
> +     id => "add_watching"

Nit: Line up =>

::: extensions/RequestNagger/template/en/default/email/request_nagging-requestee.txt.tmpl
@@ +21,5 @@
> +  [%+ request.flag.age %] from [% request.requester.identity %]
> +  [%+ urlbase %]show_bug.cgi?id=[% request.bug.id +%]
> +  [% IF request.attachment && request.attachment.ispatch %]
> +  Review: [% urlbase %]review?bug=[% request.bug.id %]&attachment=[% request.attachment.id %]
> +  [% END %]

Missing request defer link.

Comment 29

[:glob ✱]

thanks for the review dkl :)

we're planning to deploy this early next week, which will give us the chance to quickly fix any issues that may arise following the first batch of emails.

Comment 30

[:glob ✱]

schema only:

Committing to: bzr+ssh://[e-mail]/bmo/4.2/
added extensions/RequestNagger
added extensions/RequestNagger/Config.pm
added extensions/RequestNagger/Extension.pm
Committed revision 9102.

Comment 31

[:glob ✱]

Committing to: bzr+ssh://[e-mail]/bmo/4.2/
modified .htaccess
modified userprefs.cgi
modified extensions/RequestNagger/Extension.pm
added extensions/RequestNagger/bin
added extensions/RequestNagger/lib
added extensions/RequestNagger/template
added extensions/RequestNagger/web
added extensions/RequestNagger/bin/send-request.nags.pl
added extensions/RequestNagger/lib/Constants.pm
added extensions/RequestNagger/lib/TimeAgo.pm
added extensions/RequestNagger/template/en
added extensions/RequestNagger/template/en/default
added extensions/RequestNagger/template/en/default/account
added extensions/RequestNagger/template/en/default/email
added extensions/RequestNagger/template/en/default/hook
added extensions/RequestNagger/template/en/default/pages
added extensions/RequestNagger/template/en/default/account/prefs
added extensions/RequestNagger/template/en/default/account/prefs/request_nagging.html.tmpl
added extensions/RequestNagger/template/en/default/email/request_nagging-requestee-header.txt.tmpl
added extensions/RequestNagger/template/en/default/email/request_nagging-requestee.html.tmpl
added extensions/RequestNagger/template/en/default/email/request_nagging-requestee.txt.tmpl
added extensions/RequestNagger/template/en/default/email/request_nagging-watching-header.txt.tmpl
added extensions/RequestNagger/template/en/default/email/request_nagging-watching.html.tmpl
added extensions/RequestNagger/template/en/default/email/request_nagging-watching.txt.tmpl
added extensions/RequestNagger/template/en/default/hook/account
added extensions/RequestNagger/template/en/default/hook/admin
added extensions/RequestNagger/template/en/default/hook/bug
added extensions/RequestNagger/template/en/default/hook/global
added extensions/RequestNagger/template/en/default/hook/account/prefs
added extensions/RequestNagger/template/en/default/hook/account/prefs/prefs-tabs.html.tmpl
added extensions/RequestNagger/template/en/default/hook/admin/products
added extensions/RequestNagger/template/en/default/hook/admin/products/edit-common-rows.html.tmpl
added extensions/RequestNagger/template/en/default/hook/admin/products/updated-changes.html.tmpl
added extensions/RequestNagger/template/en/default/hook/bug/show-header-end.html.tmpl
added extensions/RequestNagger/template/en/default/hook/global/setting-descs-settings.none.tmpl
added extensions/RequestNagger/template/en/default/hook/global/user-error-errors.html.tmpl
added extensions/RequestNagger/template/en/default/pages/request_defer.html.tmpl
added extensions/RequestNagger/web/js
added extensions/RequestNagger/web/style
added extensions/RequestNagger/web/js/requestnagger.js
added extensions/RequestNagger/web/style/requestnagger.css
added extensions/RequestWhiner/disabled
modified skins/custom/global.css
modified template/en/default/account/prefs/settings.html.tmpl
Committed revision 9103.

Comment 32

[:glob ✱]

while testing on allizom i found a security issue -- emails which reference non-public bugs are not encrypted by securemail.

i've disabled the extension, re-enabled RequestWhiner, and will work on a fix asap.

Comment 33

[:glob ✱]

Attachment: 892615_4.patch

this patch sits atop the current patch.

if any of the bugs are not public, and the user has provided their public key, then the email will be encrypted.  if there are private bugs and the user hasn't provided their public key, the summary of the private bugs will be changed to "(Secure bug)" and the email left unencrypted.

Comment 34

[David Lawrence [:dkl]]

Comment on attachment 823818 [details] [diff] [review]
892615_4.patch

Review of attachment 823818 [details] [diff] [review]:
-----------------------------------------------------------------

Works fine except when SecureMail is disabled, then bug.tooltip does not exist and the HTML title attributes are empty. Either add a monkeypatch method to Extension.pm to add tooltip to a bug object by default, or convert SecureBug.pm to Bug.pm and always subclass to bring in tooltip support. Since we have SecureMail enabled on BMO anyway I am not r- but would like to see this fixed. r=dkl.

Comment 35

[:glob ✱]

went with the always-subclass approach:

Committing to: bzr+ssh://[e-mail]/bmo/4.2/
modified extensions/RequestNagger/bin/send-request-nags.pl
added extensions/RequestNagger/lib/Bug.pm
modified extensions/RequestNagger/template/en/default/email/request_nagging-requestee.html.tmpl
modified extensions/RequestNagger/template/en/default/email/request_nagging-watching.html.tmpl
modified extensions/SecureMail/Extension.pm
Committed revision 9109.

Comment 36

[:glob ✱]

this is now live :)

Comment 37

[:glob ✱]

i've changed the reminder interval from 7 days (the default) to 1 day on the following products:

- Firefox
- Firefox OS
- Firefox for Metro
- Firefox for Android
- Core
- Toolkit

Comment 38

[Ed Morley [:emorley]]

Could we add "Release Engineering" to that list?

Comment 39

[:glob ✱]

(In reply to Ed Morley [:edmorley UTC+1] from comment #38)
> Could we add "Release Engineering" to that list?

releng's interval has been changed to 1 day.

Comment 40

[Ed Morley [:emorley]]

Thank you :-)