--On Wednesday, September 29, 2021 09:52 -0500 Robert Sparks
<rjsparks@xxxxxxxxxxx> wrote:
>...
> Similarly, the "string of interims announcements" that was
> brought up is the way it is now because people _asked_ for one
> message per session that they could easily search for and
> easily visually scan for these (with the date) by subject. It
> started as one message. I'm happy to change this to
> whatever/wherever, but recognize that what's happening now was
> shaped by community feedback.
Robert,
I think this is a perfect example of where more careful thinking
about the problem is important and where "more lists" are
perhaps just a distraction. Probably this categorization is not
quite right two, but, for the interim announcements for a given
WG, I suggest that there are the following kinds of IETF
participants:
(1) Participants in the WG and (hence) subscribers to its
mailing list.
(2) People in the same area (small-"a") of work [1] who want to
track the WG but rarely, if ever, participate in any active way.
(3) People in other areas who might be curious about what is
going on.
(4) People who don't care whether that WG is meeting or not and
might prefer to not be told about it.
Now, for (1), separate, per-meeting, announcements might be just
right and, if people want them that way, they should continue to
go the per-WG mailing lists. For (2) and (3) one announcement
for multiple interim meetings is likely just fine and that
announcement would be much more useful (and probably read more
often) if the announcement contained tentative agendas. And,
for (4), the announcements are just noise, noise which those
people might prefer to have sent only to the unimportant-news
list to which almost no one would subscribe.
And, while I can't recommend either (partially because of the
tooling and complexity involved), the combination of groups (1)
and (2) are a case for either separate "announce" and
"discussion" lists for each WG or for being able to subscribe to
particular announcement postings based on metadata like topic
keywords, Area, and so on rather than treating these issues as
ones that can be solved by the rather blunt instrument of
fragmenting lists.
best,
john
[1] This will often conform to our Areas, but not always, and
that is another issue.
