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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 Sep 2015 09:49:49 -0500

Barry,

On Mon, Aug 31, 2015 at 5:53 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

>
>
> Sent from my iPad
>
> > On Aug 31, 2015, at 5:51 PM, Barry Leiba <[email-masked]>
> wrote:
> >
> > 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.
>
> I agree with that.

I've had that question, too. I think it's worth discussing.

Normally, we'd want the responsible AD, but when we have the responsible AD
who isn't available, the other AD(s) in the area probably do benefit from
having context.

The longest period of unavailability I've seen recently was when Wes Eddy
stepped down at the first IETF in 2013, and I wasn't named as his
replacement for a couple of months, and that gap could have been longer.
I'd guess Martin benefited from from not starting at zero with Wes's
working groups during that time.

You, and the other ADs serving at the time, would know more about that than
I do, of course.

(And when Martin gets back from vacation in a week or two, we can ask him
:-)

There may have been longer periods; I just don't know.

But, worth discussing.

Spencer

> Alvaro

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 Sep 2015 10:22:07 -0500

I responded to Barry/Alvaro on his #3 separately, but just to follow
through ...

On Mon, Aug 31, 2015 at 4:51 PM, Barry Leiba <[email-masked]>
wrote:

> Robert, thanks so much for dealing with this!

Spencer echo's Barry's thanks ...

> I see a few things I have questions about:
>
> 1. Why does last_call_expired go to iesg?  Shouldn't it be doc_ad?

I'd agree.

Aside: I don't even use these for my own documents (although I imagine
other ADs find this useful for their own documents). I either put things on
telechat agendas when I'm issuing Last Calls or when I'm working through
the AD dashboard entries. But maybe if TSV had more documents in flight
simultaneously ...

> 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?

I'd agree with Barry here.

> 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.

4. On these two:

charter_external_review To: ietf_announce
                        Cc: group_mail_list

charter_external_review_new_work To: new_work

Are there charters that go to external review, that DON'T go to New Work?
https://tools.ietf.org/html/rfc6756 has this:

   The IETF maintains a mailing list for the distribution of proposed
   new work items among standards development organizations.  Many such
   items can be identified in proposed Birds-of-a-Feather (BOF)
   sessions, as well as draft charters for working groups.  The IETF
   forwards all such draft charters for all new and revised working
   groups and BOF session announcements to the IETF new-work mailing
   list.

(I apologize for not knowing for sure, but I think that's the only RFC that
describes how this works. But maybe something has changed since I moved
from the IAB to the IESG)

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

And to me.

Spencer

> 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
> > 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: Tue, 1 Sep 2015 12:46:07 -0400

> replacement for a couple of months, and that gap could have been longer. I'd
> guess Martin benefited from from not starting at zero with Wes's working
> groups during that time.

It wouldn't make a difference for me, though for other ADs who work
differently, it might.  For my part, when I get messages about
documents that "belong" to another AD, I usually delete them.  I might
take a quick look, but I might not.  If we re-shuffled things and I
took over that working group later, the mail I got earlier because I
was on the "docname-ad" alias wouldn't help give me context, because I
didn't pay enough attention to it for that.

Barry

---

From: Robert Sparks <[email-masked]>
Date: Tue, 01 Sep 2015 12:37:40 -0500

On 9/1/15 10:22 AM, Spencer Dawkins at IETF wrote:
>
> 4. On these two:
>
> charter_external_reviewTo: ietf_announce
>                         Cc: group_mail_list
>
> charter_external_review_new_workTo: new_work
>
> Are there charters that go to external review, that DON'T go to New 
> Work? https://tools.ietf.org/html/rfc6756 has this:
>
> (I apologize for not knowing for sure, but I think that's the only RFC 
> that describes how this works. But maybe something has changed since I 
> moved from the IAB to the IESG)
>
>
These are separate more to allow control of what appears in the headers 
of what goes to the new-work list than to enable sending to new-work or 
not. (Even if they are always both sent, we shouldn't try to do it with 
one message).

The normal workflow would be to send both messages. The tool will allow 
the secretariat to send to only one, at the direction of the IESG.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 Sep 2015 14:34:29 -0500

Hi, Robert,

On Tue, Sep 1, 2015 at 12:37 PM, Robert Sparks <[email-masked]> wrote:

> These are separate more to allow control of what appears in the headers of
> what goes to the new-work list than to enable sending to new-work or not.
> (Even if they are always both sent, we shouldn't try to do it with one
> message).
>

Ah, thank you for clearing that up for me. The split makes perfect sense
now.

Spencer