Re: [Gendispatch] Let's restore and evolve our plenary function (Re: Ending [e-mail])

[Pete Resnick <[e-mail]>]

[Hopefully obvious, but with no hat on.]

Some of the things you mention can be done with current tools, though 
admittedly not all of them are the easiest to use. For example:

On 3 Apr 2021, at 23:27, Keith Moore wrote:

> On 4/3/21 12:54 PM, Eliot Lear wrote:
>
>> Rather than view this as a complete negative, I suggest that we take 
>> this as a challenge to find an industry-leading way to improve 
>> overall decision making and discourse in an environment where rough 
>> consensus matters, without us getting too… rough.
>
> I have been wondering for awhile whether some enhancements to our 
> means of distributing email to subscribers could yield a better 
> experience for ietf@ in particular and perhaps other lists also. 
> Imagine that instead of the list simply sending every message to every 
> subscriber, the list could do per-subscriber filtering according to 
> each subscriber's preferences.   Then a reader who got tired of a 
> certain thread could press a "Don't show me any more messages from 
> this thread" button.  The messages would still be archived so they 
> wouldn't be inaccessible to the reader, but the reader wouldn't be 
> interrupted by seeing such messages arrive or need to bother with 
> deleting.

Two things here:

First, you'll note that in the mailman options for every list, there's a 
box which says:

-----

**Which topic categories would you like to subscribe to?**

By selecting one or more topics, you can filter the traffic on the 
mailing list, so as to receive only a subset of the messages. If a 
message matches one of your selected topics, then you will get the 
message, otherwise you will not.

If a message does not match any topic, the delivery rule depends on the 
setting of the option below. If you do not select any topics of 
interest, you will get all the messages sent to the mailing list.

-----

The only problem here is that topics are defined by the list admin, 
which takes some work, and you can only update which topics you want to 
subscribe to through the web interface, which is a bit of a pain.

However, there is a second possibility, and it applies a bit to some of 
the below: There is now imap.ietf.org running an IMAP server containing 
all of the IETF list archives. It's all I use now to read my IETF list 
mail; I have turned off delivery of messages to my Inbox. Not only do 
most IMAP clients allow you to subscribe to only particular mailboxes 
(i.e., IETF lists), but most also have a lovely set of filter options 
such that you can view only messages that match filter criteria you 
specify on a per mailbox basis (or across mailboxes). I've been 
recommending to people for some time to move over to reading IETF mail 
on the IMAP server.

> Another possible enhancement would allow a subscriber to follow a 
> thread as it moved from one list to another.   That way, discussions 
> could easily be taken off the "main" list of a particular group and 
> moved to a "side" list.   So when, say, the ietf@ list gets into 
> discussions between a small number of people, the moderator could say 
> "take it off the ietf@ list and report back to us if/when you have 
> reached some sort of agreement".   The discussion could move 
> seamlessly (anyone who had contributed to the thread would 
> automatically start seeing the side list traffic), and anyone else who 
> wanted to follow that traffic could also watch those messages (or stop 
> watching them) with a single button click.   Everything would still 
> get archived with topics retained in the message headers.
>
> (really, "lists" in this environment become more like "topics")

Yeah, this one is more interesting. It could be dealt with using mailman 
topics, but could really use some specific tooling.

> Another possible enhancement might be "remove me from replies to this 
> thread".   The list software would then remove that subscriber from 
> to/cc headers of messages from that thread that are posted to the 
> list.   This wouldn't keep readers from doing "reply all" to 
> messages they had already received, but it would reduce the number of 
> replies sent to recipients who no longer wanted to be in a particular 
> discussion.

This is the old usenet "kill thread" command; easily implemented in 
IMAP, somewhat more complicated on the server side.

> Another possible enhancement would be "upvote" / "downvote" in 
> response to a particular message from a list, and readers would see 
> the number of upvotes and downvotes when they (re)read the message 
> from the list or read it in the archive.   This would reduce the 
> number of messages posted for no other reason than to say "+1".   
> (I've implemented this using <IMG> tags to point to images of the 
> respective vote counts.   The results certainly weren't perfect, 
> especially since many MUAs don't display images by default, but seemed 
> potentially useful.)

One possibility is of course moving to more of a forum-based messaging 
service or other non-email-based alternatives. But assuming sticking 
with email: Something like draft-crocker-inreply-react could be used. 
When Dave proposed this, I also suggested that it could be done using 
MDNs in a multipart/report format. Either might make sense here. Of 
course, again this puts the burden on the client to deal with.

I agree with your caveats, but I also agree that this is something worth 
pursuing.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best