One detail that's a consequence of what's below that I wanted to highlight:
If a group is getting copied on the state change notices for a document
right now, it's because the group is listed in the "Send notices to"
(aka Notify) field in the datatracker. If a chair wants to alter that
for a document (or all documents for a group), they can do so by editing
the notify field (or asking their AD to do so). In any case, I suggest
coordinating that with the appropriate AD given what's in the links I
sent below.
RjS
On 2/9/15 2:11 PM, Robert Sparks wrote:
Hi Brian:
There are a couple of moving targets in what you're objecting to that
I think we need to be careful to tease apart.
Here's a bit of detail to help with that (I hope):
1) the .all alias includes any address that is covered by any other
generated alias (currently that's .authors, .chairs, .ad, and .notify)
2) the .notify alias is populated directly from the Notify field for a
draft in the tracker. You can see what that's currently set to for a
draft by looking at the "Send notifications to" line on the document's
main page.
3) The IESG directed that when a working group draft begins IESG
processing, the working group be added to the notify field by default.
See
http://www.ietf.org/mail-archive/web/wgchairs/current/msg12989.html
and
http://www.ietf.org/mail-archive/web/wgchairs/current/msg12992.html
So, I _think_ the conversation you need to be having to address your
objection is with the IESG on the decision to add the group to the
default notification list.
That said, there are some things we're doing to the aliases to make
where things are coming from easier to figure out. None of what's
below will change whether a working group gets the state-change
notifications, but it may help explain other aspects of what you've
been recently seeing.
4) We're working on providing pages that show the expansions of the
aliases at ietf.org similar to the pages that are at tools.ietf.org.
This isn't happening immediately because the mail processing systems
are different, and there are some extra gears that we're having to
incorporate.
5) The most recent datatracker releases have made incremental changes
to the way the aliases are used. In particular, mail sent through the
aliases should end up with fully expanded To header fields at this
point. We are also working on adding the fields (already present when
using @tools.ietf.org aliases) that make it easy to see exactly what
alias got invoked.
6) From the links above, you'll see that part of the original
implementation was to add .all to the Notify field (in addition to the
working group). That led to some trouble since .all contains .notify -
there's an include loop, and some of the dynamics of integrating with
the mail handling at @ietf.org vs @tools.ietf.org led to not catching
that loop in the right place (this was affecting a few drafts last
week). This has been addressed, both by more careful loop protection,
and by changing what gets put in Notify to not use .all directly.
Again, those last 3 items are just part of the context - they don't
affect the primary concern you're raising. That lives solidly with
spirit of the decision at item 3) above.
RjS
On 2/9/15 1:00 PM, Brian E Carpenter wrote:
Hi,
I see that the tracker has started using email aliases of the
form draft-ietf-WG-*.all@xxxxxxxx to report on state changes,
and that these aliases now apparently include the WG as well
as the interested parties.
This is highly obnoxious. One problem is that for most recipients
the messages are pure noise (and any follow-up messages whose CC
list isn't manually pruned are additional noise). Another problem
is that they are in effect BCC'ed to the WG, so existing filters
don't catch these messages. A consequent problem of that is that
many people are likely to do what I'm about to do: figure out how
to spam filter all this noise, thereby risking to miss any such messages
that actually matter.
Please please please remove the WG lists from these aliases.
If something really needs to be brought to the WG's attention,
there are people who know they should do that.
Regards
Brian Carpenter