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

["Livingood, Jason" <[e-mail]>]

Very interesting list of desired features - hopefully it generates some brainstorming from others. I know we all like to quickly jump to possible technical solutions but this may be a case where continuing to define requirements/features/problems as below is better than jumping ahead too quickly. At some point some experiments will add value too.

On 4/4/21, 12:28 AM, "Gendispatch on behalf of Keith Moore" <[e-mail] on behalf of [e-mail]> 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.

    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")

    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.

    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 of the main problems with email in general is that it has become the
    default dumping ground for messages of dubious or marginal relevance
    from numerous sources.  This isn't just spam but also status messages,
    reminder messages, "you got a message on this other service (but we
    won't tell you what it is)" messages, you need to change your password,
    your disk storage is over quota, etc.   The overall interrupt overhead
    is too high.  So every extraneous message becomes that much more
    annoying.  Reducing the number of extraneous messages while still
    keeping the reader in control of what they see seems like a good idea.

    I think the hardest part of implementing something like this is that it
    has to take as input a lot of messages in either plain text or various
    dialects of HTML and modify each message so that buttons can be added to
    the version of the message sent to each subscriber.   I've experimented
    with some of this in the past (e.g. trying to add an upvote/downvote
    button for each paragraph).   That didn't work nearly so well as I would
    have liked because it was hard to identify real paragraph boundares in
    the actual HTML sent in email messages - or for that matter in plain
    text email - but if the only place we need such buttons is on a
    per-message basis I think it's doable.

    Anyway I think experiments along these lines could be fruitful, and I
    wonder if anyone else would like to help with this.

    Keith


    --
    Gendispatch mailing list
    [e-mail]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/gendispatch__;!!CQl3mcHX2A!XKd6cyD1NQ13Y-hNEl_1R_fLFRvQq0sTl7u0zrLSDXUAB_BdmxWhHmnYYJLoVyVGZPBUhA$