> I'm arguing that Last Call messages are of such importance to the
> standards-making goal of the IETF that we really do have to send them
> to as much of the community as we can.
The trouble with that is that if you really believe that and take it completely, we would be posting last-call announcements to every mailing list we have: all the WG lists, all the non-WG lists, all the lists that remain from closed groups, and whatever else. I think few of us would like that.
If my last sentence is correct, then we really do have to understand that it’s more important to make sure that participants understand the importance of last call and where to find the last-call announcements… and then leave it to the community to do what they’re willing to do with that. And that does not meal trying to force those announcements on people who don’t want them.
It was different when the IETF was smaller. We need to accept that things have changed.
Barry
On Wed, Sep 29, 2021 at 6:50 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 30-Sep-21 11:28, Jay Daley wrote:
>
>
>> On 30/09/2021, at 10:13 AM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx <mailto:brian.e.carpenter@xxxxxxxxx>> wrote:
>>
>> 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.
No worries, I don't feel picked upon.
> 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.
Indeed. That's why I understand the goal of significantly reducing the list traffic.
> 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.
Sure. (Nevertheless, the traffic on the announce list is so tiny compared
to my daily spam load that it's very hard to perceive it as a problem.)
> So far, I’ve heard the following broad reasons for not breaking
up ietf-announce into multiple lists:
I'm not arguing against that, when linked to weekly summary messages. I'm
arguing that Last Call messages are of such importance to the standards-making goal of the IETF that we really do have to send them to as much of the community as we can.
> 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.
Yes.
Brian
>
> 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 <mailto: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
>
> --
> Jay Daley
> IETF Executive Director
> exec-director@xxxxxxxx <mailto:exec-director@xxxxxxxx>
>
