Subject: [Manycouches] Fwd: New Version Notification for draft-shmoo-async-00.txt

From: Mallory Knodel <[email-masked]>
Date: Wed, 4 Nov 2020 14:55:30 -0500

Hi all,

This draft attempts to document some of the practises that I learned, 
and that my co-author Karel Novotný employs regularly, in using mailing 
lists for asynchronous, time-bound meetings. Looking forward to refining 
this and talking about it at the 109 shmoo meeting,

-Mallory

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-shmoo-async-00.txt
Date: 	Mon, 02 Nov 2020 15:49:57 -0800
From: 	[email-masked]
To: 	Karel Novotny <[email-masked]>, Karel Novotný <[email-masked]>, 
Mallory Knodel <[email-masked]>

A new version of I-D, draft-shmoo-async-00.txt
has been successfully submitted by Mallory Knodel and posted to the
IETF repository.

Name: draft-shmoo-async
Revision: 00
Title: Meeting asynchronously with mailing lists
Document date: 2020-11-02
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/archive/id/draft-shmoo-async-00.txt
Status: https://datatracker.ietf.org/doc/draft-shmoo-async/
Htmlized: https://datatracker.ietf.org/doc/html/draft-shmoo-async
Htmlized: https://tools.ietf.org/html/draft-shmoo-async-00

Abstract:
For when we can't meet in person, when there's interim work to be
done, or just because the task calls for it, an asynchronous text-
based meeting can sometimes be perfectly productive and useful.
Given how much the IETF uses email already this document
aims to create additional guidance for co-chairs and meeting
facilitators who might want to host a meeting asynchronously with
mailing lists. Drawing from decades of facilitation experience in
global networks, the document also treats unique considerations for
facilitators that are introduced by this meeting methodology.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 17:35:10 -0500

Hi, thank for this interesting and really very relevant document.
I hope Ted Lemon will read it.

I read through it hoping for an example, and there it was in section 4.2.
But it was too short!   I feel that I need more details.

Is there perhaps a public archive where this method has been used for real?
I wish to learn to do this better.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2020 13:51:55 +1300

Hi,

CSCW (Computer-Supported Cooperative Work) has been a topic for many years, in fact since before the WWW was invented, to my personal knowledge. I suspect that there's a lot of published knowledge in this area, and human evolution since the 1980s has been rather limited, so most of that knowledge should be applicable. Maybe we can find some experts.

(We just missed the latest conference: https://cscw.acm.org/2020/ )

About this specific proposal:

> Reply to any thread at any time, just make sure to keep the subject line intact so it is clear on what topic you are responding.

What actually happens in the IETF is that people fail to change the subject line when they change the actual subject, which I find intensely annoying. Once a thread has diverged from its nominal subject, and asynchronous replies have forked the thread, a thread becomes essentially useless and I tend to delete such threads wholesale. Am I unusual?

Also, what is really new here? IETF WGs are *always* in session by email 24x7, and good WG Chairs frequently set a short-term agenda, ask specific questions to the WG, start threads with deadlines (which we tend to call last calls, but not always), and summarise and extract a consensus at the end. I'm not clear what we gain by declaring some unit of time to be a "meeting".

Related to that:

>  3.4. Compliance
> 
> Lastly delivery of the Note Well and other compliance considerations when meeting only on a mailing list need to be explored further.

There's absolutely no difference from that point of view. All usage of an IETF mailing list always falls under IETF rules. It would be a very good thing if mailman welcome messages (like 'Welcome to the "Manycouches" mailing list') included a pointer to the Note Well. So should mailman sign-up pages like https://www.ietf.org/mailman/listinfo/manycouches

(My goodness, I should have noticed those omissions 20 years ago.)

There should be no "other compliance considerations" that aren't covered by the Note Well. If there are, that's a bug in the Note Well text.

One other point:

>  3.1. Defining participation
> 
> There are yet unexplored models for how to host a full IETF meeting held only on mailing lists given subscription to lists isn't monetised. It isn't recommended to hold an asynchronous meeting over several days, 

On the contrary. Because of time zones and differing sleep/wake/work cycles, no serious technical thread can be conclusive in less than several days; I would say a full week is the minimum.

Regards
   Brian

On 05-Nov-20 11:35, Michael Richardson wrote:
> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches
>

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 5 Nov 2020 09:56:44 -0500

Hi Michael,

> But it was too short!   I feel that I need more details.

I'd love more examples, too. APC has so much experience, but it would be 
nice to find others so that we can iterate and pull out best practice. 
Maybe a "to do" is to look around and survey for relevant examples-- 
Brian sent a pointer to a body of work in his reply.

> I wish to learn to do this better.

I'd also like to find more "cautionary tales" as I think learning from 
mistakes can be really instructive. More fails, please,

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 5 Nov 2020 10:08:32 -0500

Hi,

> (We just missed the latest conference: https://cscw.acm.org/2020/ )

Thanks-- Like Michael I think it would be useful to have other specific 
*examples* to draw from. Then the things that seem to work best for the 
IETF could be pulled out.

> Also, what is really new here? IETF WGs are *always* in session by email 24x7, and good WG Chairs frequently set a short-term agenda, ask specific questions to the WG, start threads with deadlines…
I think it's different because it's a meeting-- the same sorts of things 
that we get out of synchronous moments in a hotel in some city, except 
without the tea and biscuits. And while we're at it why not remove 
strict time constraints?
> There should be no "other compliance considerations" that aren't covered by the Note Well. If there are, that's a bug in the Note Well text.

Yeah, I was just unsure here. I'd love to clean up this section or 
remove it all together.

> On the contrary. Because of time zones and differing sleep/wake/work cycles, no serious technical thread can be conclusive in less than several days; I would say a full week is the minimum.

I'd say it really depends on the agenda, since this is meant to look at 
a specific WG/RG not the whole IETF, but sure a week seems rather 
perfect. In fact, I think I might have meant to say "... over several 
weeks ..."?

-Mallory

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2020 11:30:08 -0500

> mistakes can be really instructive. More fails, please,

Well, as a WG participant, I delete emails sent by mis-configured LookOut
users where they think they can mark their text in purple, or with [myname]:

I just delete them unread. sorry.
I know of no other useful way to giving them feedback.

As a WG chair, I try to puzzle out what they are saying, and I often, if I
reply, fix all their quoting, which really only takes me about 20s, and WTF
can't they learn how to use a 30year-old technology?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Nov 2020 16:51:38 +0000

A reply back, at least once, that says "plaintext please" might be more useful than just tossing it which provides zero feedback as you probably know.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2020 08:52:20 +1300

> A reply back, at least once, that says "plaintext please" might be more useful than just tossing it which provides zero feedback as you probably know.

Somebody *really* brave could write a draft on how to use email properly for IETF discussions.

Just a few of the small items it could consider:

Plain text v rich text
Monochrome v colo(u)r
Font
Wrapped v flowed
>>> Quoting
<snip> v ... v no snipping at all
Top posting
User agents to be avoided/preferred

Have fun writing it; the discussion should be lively.

   Brian

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 5 Nov 2020 15:03:23 -0500

> Have fun writing it; the discussion should be lively.

I honestly can't believe this doesn't exist already because it really 
should. But maybe as part of the Tao or EDU team resources.

Better yet a reference from some decades ago would probably be more 
helpful, genuine and wouldn't require bravery. I'd be happy to cite it 
in this draft.

-Mallory

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2020 15:56:24 -0500

Mallory Knodel <[email-masked]> wrote:
    >> Somebody *really* brave could write a draft on how to use email
    >> properly for IETF discussions.  Just a few of the small items it could
    >> consider:
    >>
    >> Plain text v rich text Monochrome v colo(u)r Font Wrapped v flowed
    >>>>> Quoting
    >> <snip> v ... v no snipping at all Top posting User agents to be
    >> avoided/preferred
    >>

    > should. But maybe as part of the Tao or EDU team resources.

It seems like we've done this multiple times.

Then the "vendors" remove those options, or move the setting elsewhere.
People say, "but by company makes me use product X", and now you know why
so many people are john.smith.ietf@ some-provider.example.

---

From: "John Levine" <[email-masked]>
Date: 5 Nov 2020 16:10:13 -0500

It'd be interesting to see how many of our colleagues have not yet
noticed that it's coming up on 25 years since we put MIME on the
standards track.

While I can see some reasonable advice like keeping in mind that not
everyone can see colors and other formatting, good luck keeping the
religious issues out of it.

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Nov 2020 21:27:51 +0000

So roughly the same as IPv6.  I wonder how many arguing for "only plaintext email" are also arguing for "IETF should not use IPv4-only sites"

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2020 13:22:02 +1300

> So roughly the same as IPv6.  I wonder how many arguing for "only plaintext email" are also arguing for "IETF should not use IPv4-only sites"

I don't think it's comparable. For productive email discussions, we need some sort of presentation-layer standard that doesn't seem to exist, but it will inevitably have a lowest-common-denominator aspect so that as many user agents as possible can handle it.

    Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Nov 2020 00:50:22 +0000

>    I don't think it's comparable. For productive email discussions, we need some sort of presentation-layer standard that doesn't seem to exist, but it will inevitably have a lowest-common-denomina…

If after 25 years your MTA cannot handle MIME, you should seriously consider another MTA.  Same argument people make about IPv6/v4.

I believe they are EXACTLY comparable.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2020 17:37:20 +1300

> I believe they are EXACTLY comparable.

I don't understand what you are saying. My MTA has no problem handling MIME, but when people start sending messages in tiny fonts, or they destroy fixed-width formatting and threading using >>>, or try to use colour to distinguish comments from older comments, it's perfectly valid MIME but virtually useless for multiple rounds of discussion like this thread.

The text/plain, if present, is usually a mangled mess at that point.

Unfortunately it only takes one poster in a complex thread to introduce that kind of typographical salad, and that sub-thread is bust.

I don't have any examples because I delete them, and anyway we don't want to name and shame.

Regards
   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 6 Nov 2020 14:35:05 +0000

>    I don't understand what you are saying.

Little more than what I first said: MIME is a standard, just like IPv6.  I'm sure router vendors have things to say about IPv6 analogous to the way people complain about MIME-enabled typography. We're not going back to IPv4 and we're not going back to just plaintext email.

---

From: Jay Daley <[email-masked]>
Date: Sat, 7 Nov 2020 07:33:59 +1300

> On 7/11/2020, at 3:35 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

Maybe the community could just specify a recommended minimum font size (and maximum message length?) along with a warning "your message is likely to be ignored if you are outside of these recommendations"?

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Nov 2020 08:53:49 +1300

On 07-Nov-20 07:33, Jay Daley wrote:
> 
> 
>> On 7/11/2020, at 3:35 AM, Salz, Rich <rsalz=[email-masked] <mailto:rsalz=[email-masked]>> wrote:
>>

It's more than that, as I have tried to explain. Next time I see one of these alphabet soup threads I will capture it as an example.

    Brian

---

From: "John Levine" <[email-masked]>
Date: 6 Nov 2020 16:23:10 -0500

In article <[email-masked]> you write:
>Maybe the community could just specify a recommended minimum font size (and maximum message length?) along with a
>warning "your message is likely to be ignored if you are outside of these recommendations"?

My MUA only has one font size and one color.  Better to say don't try to set
them at all.

I realize some people are stuck with organizational mail systems that slap
an ugly template on mail that causes some of these problems but I hope they
can figure out how to turn that off.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Nov 2020 16:56:20 -0500

Salz, Rich <rsalz=[email-masked]> wrote:
    > If after 25 years your MTA cannot handle MIME, you should seriously
    > consider another MTA.  Same argument people make about IPv6/v4.

I send all my MIME format text/plain email over IPv6.

    > I believe they are EXACTLY comparable.

This isn't about MIME or not.
This is about text/plain or not. That's EXPLICITELY a MIME thing.

This is about people who send nonsense text/plain content, because they only
know about text/html.  yet, the archives *DROP* text/html, so their contribution is nonsense.
Do you remember all those tests where journalists went to find out if the CEO
of Ford could change a tire, or the CEO of IBM could format a floppy?

This is the same thing.  Can elite IETFs configure their mail program to send
something understandable?  I notice the lack of a text/html part from you for
instance.  You clearly figured out how to configure your MUA.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Nov 2020 17:00:21 -0500

Jay Daley <[email-masked]> wrote:
    >> Little more than what I first said: MIME is a standard, just like
    >> IPv6.  I'm sure router vendors have things to say about IPv6 analogous
    >> to the way people complain about MIME-enabled typography. We're not
    >> going back to IPv4 and we're not going back to just plaintext email.

    > Maybe the community could just specify a recommended minimum font size
    > (and maximum message length?) along with a warning "your message is
    > likely to be ignored if you are outside of these recommendations"?

Noting that your email message's text/plain part:

1) exceeded 77 columns
2) and assumed that > text would get flowed, but did not include the required
   "format=flowed" in the text/plain specification.

3) assuming any font-size, even a minimum misses the point.
   The font-size should NEVER be specified, because that's a local decision.
   That's why text/rich had "small", and "large", rather than font sizes.
   (Yes, I have multiple mail programs that can render text/rich, but I
   stopped sending using it in the mid-1990s because there was no point)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Nov 2020 18:52:45 -0500

> can figure out how to turn that off.

I actually think that we need an RFC for this.

The person in question needs to be able to go to their IT, and needs to be
able to say, "I can not do my work until you let me configure my MUA to
comply with X"
(Of course many people just get another email account)

This may even perculate up to the vendor.