On 30-Sep-21 04:14, STARK, BARBARA H wrote:1. Announcements sent manually by <various roles> = 284
2. Announcements of new and updated WG charters & WG closures = 44
3. (included in above 44)
4. Announcements of new non-WG mailing lists = 13
5. Announcements of new RFCs = 275
6. IESG and LLC telechat announcements = 39
7. Announcements of document actions = 175
8. Announcements of IESG conflict-review results = 14
9. Last call announcements for I-Ds = 174 (+ 4 for other actions)
10. Interim WG meeting announcements = 256
The "important-news" proposal would only retain those under (1) above.
I think that 1, 4, and 6 should all be retained as is (and in the new
list, if it's created).
I think that 2, 5, 7, 8, 9, and 10 should be in a weekly summary, one
single message per week.
I have a slight problem with this proposal because if it is implemented
it would not be possible to find last call announcements by draft name.
I think this is a rather important feature when searching archive.
Unfortunately I don't have a solution for this problem.
I thought we were discussing changes to ietf-announce and not last-call. All these emails already exist on the last-call list and don't need to be repeated in their entirety on ietf-announce. A summary email to ietf-announce should be sufficient. Anybody wanting to subscribe to last-call has the ability to do so.
Unfortunately that doesn't compute. If someone sees the Last Call announcement on announce @ietf, they can simply reply and it will go where it needs to go. The whole point of last calls is they go to *everybody* so that *anybody* can reply. This is why I believe that Last Calls are possibly the most important content on announce@ and should definitely not be dropped.
I don’t mean to pick on you, but your use of the word "everybody" highlights what I see as two huge misconceptions that are affecting this discussion.
The first is the misconception that ietf-announce reaches, approximately reaches, or could theoretically reach the entire IETF community. It currently reaches a small fraction of the community (somewhere between 5-10% depending on how we define the community) and all the evidence is that it will never reach even 25% because they don’t want all those emails.
The second is the misconception of just how much we can create an engaged community by pushing messages at them. The experience from every organisation I have ever seen try this is that it’s a Pareto distribution and if you want a list that reaches everybody then it must receive virtually no messages at all otherwise people unsubscribe in such numbers that it rapidly drops below any usable approximation of everybody.
So far, I’ve heard the following broad reasons for not breaking up ietf-announce into multiple lists:
a) a detrimental effect on the process of subscribing to and managing subscription to multiple lists
b) a detrimental effect on reading/searching/finding email once those messages have been received
c) a detrimental effect on understanding what message is important and what is not and making sure nothing important is missed
d) a view that separate lists reduces overall engagement
e) a view that separate lists reduce cross-area discussion
I understand a) and c) - we need a much better interface for managing subscriptions to 100+ lists that also helps us understand the subject matter, volume and perceived importance of any list as well as what other lists are related.
For b), d) and e), while list organisation plays a part, in most practical situations there are other factors that are much more important.
Jay
I'm not against weekly summaries for most of the categories Lars listed, but I suggest that the model should be, for category X, that the raw messages go to X-announce@xxxxxxxx, and the summary comes labelled "X-announce messages for the week ending $DATE".(And yes, I know there would be complaints about too many summary messages. Or too few.) Brian
