Subject: [TOOLS-DEVELOPMENT] First look: Improved email handling in the datatracker

From: Robert Sparks <[email-masked]>
Date: Sat, 29 Aug 2015 19:48:38 -0500

All -

At this year's IAB/IESG retreat we discussed making the recipients of 
the email
messages the datatracker sends more configurable, reducing the number of 
messages
sent for a given action, and making the messages themselves more meaningful.

One of the primary goals was to make it so that the people who needed to
receive each message would receive the message by default, and we would stop
doing things like putting document shepherds in the notify field. The intent
now is for the notify field to be empty most of the time, only containing
addresses that are special cases.

We made a great deal of progress on this front and have some changes ready
for you to look over and test. There are many things here that need 
feedback.
Please take a few moments to poke around this. If you don't find any 
showstoppers,
I'll send this to the wg-chairs list mid-week.

Start with <https://dt-test.rjsparks.org/mailtoken/token>
(This is a development instance of the tracker - you can log in as 
anyone using
their datatracker login name and the password "password").
You'll see a list of actions on the left, and recipients on the right.
Mouse over any of them for a short pop-up description.
You can focus on a particular action by going to, for example,
<https://dt-test.rjsparks.org/mailtoken/token/last_call_issued/>

The recipients listed are table driven - the secretariat can change them.
Note that the actions are configured at the moment to reach more people than
the production system currently does in many cases. One of the most 
important
things you can do is provide feedback on whether we have the set of 
recipients
for a given action right. Another is whether we have the right actions 
listed -
in other words, are there times when we send email now that we 
shouldn't, and
are there other times where we aren't sending email that we should? 
(Note that
there are small number of places that the tracker sends email that are 
not yet
using this system, but if you spot a place that's not covered here, 
please ask
about it.)

Before brute-forcing your way through the first link above, however, let me
introduce a few other new things. If you go to a specific document, or a 
group,
there is now a tab on the main page that shows what the email expansions 
turn
into for that document or group. For example, look at
<https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications>
and note the "Email expansions" tab that takes you to
<https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/email/>

The way each recipient is computed is shown at
<https://dt-test.rjsparks.org/mailtoken/recipient/>
Again, you can hover over a token for a short text description, or focus on
a particular recipient using, for example,
<https://dt-test.rjsparks.org/mailtoken/recipient/doc_shepherd>

Wherever possible, the recipient is expanded using a Django template.  
When the
logic for expanding a recipient is too complicated for a template, the 
work is
done using a short function, as shown on the recipient page.  As we go 
forward,
we'll be working to simplify this gathering process so that many of the
recipients that require functions now can be moved into templates (but 
it will
be important to not just bury the details of the truly complicated 
recipients -
one of the other goals of this project is to make it less of a mystery where
mail is sent)

Now, the IESG will be particularly interested in one special case: Look 
at the
list of recipients for ballot_saved.  The save-and-send email form will 
offer
all of the addresses that are expanded from these recipients and allow the
AD to chose which recipient tokens to actually use (by default, all are
selected). When logged in as an AD or the Secretariat, go to
<https://dt-test.rjsparks.org/doc/draft-ietf-sipcore-refer-clarifications/ballot/425017/emailposition/?ad=107190>

Here are a few other highlights from the changes made so far:
* The secretariat has been sending the internal-review and new-work
   messages manually. The Datatracker now assists with those messages.
* The mail sent when issuing ballots has been simplified
* Instead of a generic "state changed" message, recipients get a message
   that says
   - Comment has been added
   - Intended publication status changed
   - Document has been adopted by group
   - IESG is proccessing this document

Finally, there is a script that will run when this is deployed (it has 
been run
already on this test instance) that will scrub recipients that should be
normally copied out of the Notify field for each document. The 
leadership associated
with the document will get an email message explaining the change. The 
IESG will
get a message for all the docs that do not have currently active 
leadership associated
with them (that message to the IESG will be long). Currently, when that 
script runs it
reports: Changed 4858 documents. 3775 of those had their notify field 
emptied

An example of the message that gets sent is at:
<http://www.nostrum.com/~rjsparks/example_notify_email.txt>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 31 Aug 2015 17:51:18 -0400

Robert, thanks so much for dealing with this!

I see a few things I have questions about:

1. Why does last_call_expired go to iesg?  Shouldn't it be doc_ad?

2. doc_pulled_from_rfc_queue: that goes to doc_ad and not to iesg.  I
think that might be a sufficiently unusual and remarkable situation
that maybe that one *should* go to iesg, no?

3. A question I've always had is whether it makes sense for a
document's "ad" alias to include all ADs in the area, rather than just
the responsible AD.  I can see occasions when one would want to alert
all ADs in the area, but in the vast majority of situations, I think
we want only the responsible AD.

Example of (3):
[email-masked] and
[email-masked] -- those aliases
include all three ART ADs, and probably should just include the
responsible one.

For WGs with out-of-area responsible ADs, we get this:
[email-masked]
[email-masked], [email-masked], [email-masked],
[email-masked]
That's Stephen AND the ART ADs.

What do we really want here?  I think those aliases should just
include the responsible AD, and perhaps we should have some way of
delegating for coverage during vacations and whatnot.  Otherwise, most
of the time we're sending noise to the irresponsible (ahem) ADs.

That's all I have -- the rest of it looks good.

Barry

On Sat, Aug 29, 2015 at 8:48 PM, Robert Sparks <[email-masked]> wrote:
> All -
>
> At this year's IAB/IESG retreat we discussed making the recipients of the
> email
> (This is a development instance of the tracker - you can log in as anyone
> using
> in other words, are there times when we send email now that we shouldn't,
> and
> are there other times where we aren't sending email that we should? (Note
> that
> there are small number of places that the tracker sends email that are not
> yet
> using this system, but if you spot a place that's not covered here, please
> ask
> about it.)
>
> Wherever possible, the recipient is expanded using a Django template.  When
> the
> logic for expanding a recipient is too complicated for a template, the work
> is
> recipients that require functions now can be moved into templates (but it
> will
> Now, the IESG will be particularly interested in one special case: Look at
> the
> Finally, there is a script that will run when this is deployed (it has been
> run
> normally copied out of the Notify field for each document. The leadership
> associated
> with the document will get an email message explaining the change. The IESG
> will
> get a message for all the docs that do not have currently active leadership
> associated