Subject: Old directions in social media.

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Jan 2021 12:40:13 -0500

Following on from John K.'s post and some others, I think it is about time
that the community took a hard look at some technology from the dawn of the
Web, Hurwitz and Mallery's Open Meeting which they ran for Vice President
Al Gore in 1994:

https://www.semanticscholar.org/paper/The-Open-Meeting%3A-A-Web-Based-System-for-and-Hurwitz-Mallery/78ebaf0432c105113b68675d86368c0b111c3a3e

As with many technologies (e.g. threshold cryptography), these ideas came
before the audience was ready to absorb them. A similar effect was seen in
early film. Only after the basic vocabulary of motion picture signs such as
establishing shots was understood, could film progress to more complex
narratives. The reason Facebook, a very late entrant in the social media
wars could win them (for a time at least) was that the audience had
progressed to the point where it could consume the technology.

I have seen groups trying to use git and I really wish they would stop.
Using git to run a WG provides a small amount of tool support for issues
tracking which is useful. But the tool is designed to do a very different
job and has its own bizarre vocabulary. Telling people to enter comments as
'Pull Requests' causes most people's mental gears to grind. The result is
WGs whose activities are unhappily split between a Web site and a mailing
list with no cohesion between the two. My conclusion is that for this
approach to work, there has to be a purpose written tool that absorbs the
lessons from the github experience and provides a means of following the WG
from the mailing list as well. (Which is how the open meeting worked.)

What Mallery and Hurwitz developed was a discussion forum in which comments
were organized according to a constrained vocabulary of moves that provided
a set of lightweight semantics allowing topics to be efficiently navigated.

Facebook's reaction emoticons provide a similar capability except that they
are replacements for comments rather than labels for comments. Also, since
the objective of Facebook is to maximize engagement, only positive
reactions are permitted. It is not possible to disagree (except by posting
haha to laugh in their faces). What we need most for our work is
constructive criticism. The type of comments that get us to the next level.

I still have about a month worth of effort on the first phase of the Mesh.
The second phase will include an online comment forum allowing people to
comment on the Mesh specifications. For this particular purpose, the
comment forums will of course be open and unencrypted. But part of the
point here is to provide a demonstration of the Mesh technology which
allows the discussion to be end-to-end encrypted. So a group of lawyers
working on a case could upload the case files to a cloud service and
comment on them secure in the knowledge that the cloud service provider
cannot read either the documents or the comments. Accessing end-to-end
encrypted social media will of course require a specialist client, the non
encrypted version can be presented through a Web browser interface in the
same way that Facebook, Twitter, etc. are commonly accessed.

Different types of discussion will require different sets of lightweight
semantics. For example, a forum serving a replica prop building community
(e.g. dalek building) might have semantics such as 'original', 'plans',
'techniques', etc. Someone who is going through the source video capturing
images might tag them 'original', someone who has converted that material
to plans might tag their images, plans. etc. etc.

So what is the difference between this approach and a hashtag?

There are two major differences. The first is that since hashtags come from
an infinite vocabulary, there is inevitable variation in use. Forcing
people to pick from a small number of tags makes those tags more useful as
search terms.

The second difference is process. consider a strawman IETF forum.

A forum consists of a set of documents. Each document has a status (active,
inactive, published). A pre-WG activity has a statement of scope. A WG
activity has a charter. There are also drafts, RFCs etc.

It should be possible to scan through a document and annotate individual
paragraphs with comments tagged with lightweight semantics such as:

agree
disagree
nit [typographic issues, spelling etc.]
vocabulary [use/choice of defined terms]
requirement
use-case
interop

The open meeting vocabulary was limited to six moves. It is possible that
we could make use of a slightly larger vocabulary. But it is probably best
to start out constrained and add slowly.

The process part comes in when an editor is creating a new version of the
document. We might assign an editor a separate set of moves:

accept
reject
assign-issue

So if I am editing a document and someone has given me a list of typos, I
just go through and clear them. But some comments might well require more
discussion. And we can write rules that identify those comments.

Anyway, that is what I plan to build for the Mesh. If other IETFers wish to
apply the same technology, I am always open to collaborators. At this
point, I have the majority of the components that I need to build this
tool. In particular I have the document preparation tool that accepts
either markdown or Word as either an input or an output.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 5 Jan 2021 10:37:38 +0100 (CET)

>     Il 04/01/2021 18:40 Phillip Hallam-Baker <[email-masked]> ha scritto:
> 
>     I have seen groups trying to use git and I really wish they would stop. Using git to run a WG provides a small amount of tool support for issues tracking which is useful. But the tool is designed to do a very different job and has its own bizarre vocabulary. Telling people to enter comments as 'Pull Requests' causes most people's mental gears to grind. The result is WGs whose activities are unhappily split between a Web site and a mailing list with no cohesion between the two. My conclusion is that for this approach to work, there has to be a purpose written tool that absorbs the lessons from the github experience and provides a means of following the WG from the mailing list as well. (Which is how the open meeting worked.)
> 
I'll take this chance to add - speaking of inclusiveness - that the use of git creates a barrier to participation for those whose job is not about actively developing software, either because they are not software engineers, or because they stopped developing software and moved on in their careers before git became the standard way of managing codebases. Mailing lists, on the contrary, are understood and normally used by a much broader set of people.

Any new, purpose-written discussion tool should be intuitive enough not to become a way to exclude those who cannot take a long learning curve, so that they can at least provide some input into the discussion. Actually creating standards and authoring drafts takes in itself a very long learning curve, so one may conclude that an extra bit of tool learning would not be a problem, but it would be important for people that cannot undertake that effort to be still able at least to participate in the discussion.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 11:42:50 -0500

On 1/4/21 12:40 PM, Phillip Hallam-Baker wrote:

>
> I have seen groups trying to use git and I really wish they would 
> stop. Using git to run a WG provides a small amount of tool support 
> for issues tracking which is useful. But the tool is designed to do a 
> very different job and has its own bizarre vocabulary. Telling people 
> to enter comments as 'Pull Requests' causes most people's mental gears 
> to grind. The result is WGs whose activities are unhappily split 
> between a Web site and a mailing list with no cohesion between the two.

+1

---

From: Kyle Rose <[email-masked]>
Date: Tue, 5 Jan 2021 12:08:15 -0500

I do not understand why tools need to be limited by the least common
denominator for the IETF as a whole, or limited to 1982 technology. Why is
it such a burden to ask people to learn a new tool once every 3 decades or
so? Clearly, git (along with related tooling, such as kramdown) is of great
value to many because they've spread across the IETF at (for this group) an
incredibly rapid pace.

IMO, a better response to the challenges posed by useful new tooling is to
make it more accessible, not to prohibit it.

Kyle

On Tue, Jan 5, 2021 at 11:43 AM Keith Moore <[email-masked]>
wrote:

> list with no cohesion between the two.
>
> +1
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 12:20:16 -0500

On 1/5/21 12:08 PM, Kyle Rose wrote:

> denominator for the IETF as a whole, or limited to 1982 technology. 
> Why is it such a burden to ask people to learn a new tool once every 3 
> decades or so? Clearly, git (along with related tooling, such as 
> kramdown) is of great value to many because they've spread across the 
> IETF at (for this group) an incredibly rapid pace.
>
> IMO, a better response to the challenges posed by useful new tooling 
> is to make it more accessible, not to prohibit it.

If the new tooling were anywhere nearly objectively better overall, you 
might have a point.

Why in the world should IETF penalize the vast majority of its 
participants in order to favor open source software developers? Because 
that's exactly what this is doing.   I like open source software too and 
definitely want us to be inclusive, but not at the expense of 
significantly penalizing other participants.

And I can see why the model of making it easy to submit and manage text 
changes, late in a document's development, can make sense for IETF in 
general.   But git/github is still a really poor interface for this, and 
PHB is exactly right that this actually impairs and splits the discussion.

We did the experiment.  Now it's time to stop the experiment, collect 
some results and learn from it.

Keith

---

From: Larry Masinter <[email-masked]>
Date: Tue, 5 Jan 2021 09:21:37 -0800

I think it’s fine to have the “editing team” of a working group using GitHub (not just “Git” but the whole GitHub infrastructure).

However, GitHub “Discussions” are still in beta, and not as good as a mailing list with carefully chosen Subject lines.

Asking people with architectural questions to couch them in terms of rewriting the spec isn’t much better than
telling them to go fish. This is especially true of “groups” that hold no meetings (unless you want to suggest that

“meetings” – even teleconferencing -- are 1982 technology).

It may be a fine way for a group to develop a publicly available specification that group members 
implement in an interoperable way, but why should the IETF have anything to do with it, if the
group process doesn’t admit the typical IETF cross-area industry-wide review by those who are
not so intimately familiar with the detailed vocabulary of the group’s specification to be in a position

to be able & willing to couch their questions in terms of a “Pull Request”?

--

 <https://LarryMasinter.net> https://LarryMasinter.net  <https://interlisp.org> https://interlisp.org

From: ietf <[email-masked]> On Behalf Of Kyle Rose
Sent: Tuesday, January 5, 2021 9:08 AM
To: Keith Moore <[email-masked]>
Cc: IETF Discussion Mailing List <[email-masked]>
Subject: Re: Old directions in social media.

I do not understand why tools need to be limited by the least common denominator for the IETF as a whole, or limited to 1982 technology. Why is it such a burden to ask people to learn a new tool once every 3 decades or so? Clearly, git (along with related tooling, such as kramdown) is of great value to many because they've spread across the IETF at (for this group) an incredibly rapid pace.

IMO, a better response to the challenges posed by useful new tooling is to make it more accessible, not to prohibit it.

Kyle

On Tue, Jan 5, 2021 at 11:43 AM Keith Moore <[email-masked] <mailto:[email-masked]> > wrote:

I have seen groups trying to use git and I really wish they would stop. Using git to run a WG provides a small amount of tool support for issues tracking which is useful. But the tool is designed to do a very different job and has its own bizarre vocabulary. Telling people to enter comments as 'Pull Requests' causes most people's mental gears to grind. The result is WGs whose activities are unhappily split between a Web site and a mailing list with no cohesion between the two.

+1

---

From: Kyle Rose <[email-masked]>
Date: Tue, 5 Jan 2021 12:32:02 -0500

> If the new tooling were anywhere nearly objectively better overall, you
Generally speaking, there's no such thing as "objectively better", so
that's a rather high bar to reach. But clearly there are participants who
have found GitHub to be an amazing productivity enhancement.

> definitely want us to be inclusive, but not at the expense of significantly
> penalizing other participants.
>
How is this penalizing participants? You can still engage on the mailing
list in the traditional way. No one is required to use GitHub to
participate in any WG, and chairs should push back in the event an author
implies that a PR is required for a contribution.

Does GitHub make it *easier* for those who know the tools to contribute? Of
course: that's exactly the point. Learn the tools and you too can benefit.

> PHB is exactly right that this actually impairs and splits the discussion.
It does sometimes split discussion, which is where the WG chairs need to
step in and move discussion from an issue to the mailing list when that
happens. If that isn't happening, talk to the chairs or the AD.

> We did the experiment.  Now it's time to stop the experiment, collect some
> results and learn from it.
>
>From where I sit, it's been a tremendous success. Why would we voluntarily
hamstring ourselves by moving back to a less efficient universal model for
contribution?

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Tue, 5 Jan 2021 12:46:54 -0500

> to be able & willing to couch their questions in terms of a “Pull Request”?

There are still two separate last calls for all WG documents: WGLC and IETF
LC. Even if you never followed the issues or performed periodic reviews of
document revisions prior to those checkpoints, you can always do it then.
Again, no one in any WG is required to interact with GitHub to contribute.
That contribution is easier for those who *do* use GitHub is not a
justification for prohibiting use of those tools. Equality of contribution
across the board has never been an explicit goal, and indeed contributions
to a document have always been dominated by one or a few authors who put in
a lot more work than everyone else.

Without referencing GitHub, what objective standard for access are you
advocating for, and how does the use of GitHub uniquely impact that
negatively?

Kyle

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Jan 2021 12:53:21 -0500

I am happy to have discussion such that they are in github issues and 
are meaningfully and understandably present on the email lists.

There are two problems.
One is that the current git side tooling does not do a good job of 
supporting this.  (Some peoples reactions describe it as much worse than 
"not a good job".)
The other is that a number of people have objected to the requirement 
that it be possible to effectively participate in all WG discussions via 
email.

Yours,
Joel

On 1/5/2021 12:32 PM, Kyle Rose wrote:
> On Tue, Jan 5, 2021 at 12:20 PM Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     If the new tooling were anywhere nearly objectively better overall,
>     you might have a point. 
> 
> that's a rather high bar to reach. But clearly there are participants 
> who have found GitHub to be an amazing productivity enhancement.
> 
>     participants in order to favor open source software developers?
>     Because that's exactly what this is doing.   I like open source
>     software too and definitely want us to be inclusive, but not at the
>     expense of significantly penalizing other participants.
> 
> participate in any WG, and chairs should push back in the event an 
> author implies that a PR is required for a contribution.
> 
> Does GitHub make it *easier* for those who know the tools to contribute? 
> Of course: that's exactly the point. Learn the tools and you too can 
> benefit.
> 
>     And I can see why the model of making it easy to submit and manage
>     text changes, late in a document's development, can make sense for
>     IETF in general.   But git/github is still a really poor interface
>     for this, and PHB is exactly right that this actually impairs and
>     splits the discussion.
> 
>     We did the experiment.  Now it's time to stop the experiment,
>     collect some results and learn from it.
> 
>  From where I sit, it's been a tremendous success. Why would we 
> voluntarily hamstring ourselves by moving back to a less efficient 
> universal model for contribution?
> 
> Kyle

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 13:05:18 -0500

Sent from my iPhone

> On Jan 5, 2021, at 12:32 PM, Kyle Rose <[email-masked]> wrote:
> 
> 
>> On Tue, Jan 5, 2021 at 12:20 PM Keith Moore <[email-masked]> wrote:
>> If the new tooling were anywhere nearly objectively better overall, you might have a point.
> Generally speaking, there's no such thing as "objectively better", so that's a rather high bar to reach. But clearly there are participants who have found GitHub to be an amazing productivity enhancement.

Yes, because they already knew how to use that tool, and because the use of that tool was penalizing everyone who didn’t know how to use that tool.   It’s not as if git/GitHub are “good” for editing of text documents in any other sense.  
>> Why in the world should IETF penalize the vast majority of its participants in order to favor open source software developers?   Because that's exactly what this is doing.   I like open source software too and definitely want us to be inclusive, but not at the expense of significantly penalizing other participants.
>> 
> How is this penalizing participants? You can still engage on the mailing list in the traditional way.

Right but instead of having one discussion, now there are effectively two discussions, with the GitHub one having more “pull” with the document editors.  

> No one is required to use GitHub to participate in any WG, and chairs should push back in the event an author implies that a PR is required for a contribution.
> 
> Does GitHub make it *easier* for those who know the tools to contribute? Of course: that's exactly the point. Learn the tools and you too can benefit.
>> And I can see why the model of making it easy to submit and manage text changes, late in a document's development, can make sense for IETF in general.   But git/github is still a really poor interface for this, and PHB is exactly right that this actually impairs and splits the discussion.
>> 
> It does sometimes split discussion, which is where the WG chairs need to step in and move discussion from an issue to the mailing list when that happens. If that isn't happening, talk to the chairs or the AD.
>> We did the experiment.  Now it's time to stop the experiment, collect some results and learn from it.
>> 
> From where I sit, it's been a tremendous success. Why would we voluntarily hamstring ourselves by moving back to a less efficient universal model for contribution?

Because email is actually both more efficient and fairer.  

Keith

---

From: Kyle Rose <[email-masked]>
Date: Tue, 5 Jan 2021 13:07:54 -0500

> that it be possible to effectively participate in all WG discussions via

This conceit has never been true. Conversations happen one-on-one, as well
as in person. Not every change a document goes through is discussed on the
mailing list, something that was true even in the pre-GitHub era. Editors
even make changes unilaterally, without telling anyone! (Crazy, right?)

Kyle

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 13:30:29 -0500

On 1/5/21 12:46 PM, Kyle Rose wrote:

> There are still two separate last calls for all WG documents: WGLC and 
> IETF LC. Even if you never followed the issues or performed periodic 
> reviews of document revisions prior to those checkpoints, you can 
> always do it then.

Those are the LEAST effective ways of contributing to a document, the 
LEAST likely to produce an improvement, and also the most annoying ways 
of contributing that are likely in practice to create pushback and limit 
one's effectiveness in IETF overall. Yes, they're useful as last 
resorts, but the fact that they exist is not a justification for 
crippling most potential contributors.

Keith

---

From: "Kurt Andersen (IETF)" <[email-masked]>
Date: Tue, 5 Jan 2021 10:59:20 -0800

> discussion. And we can write rules that identify those comments.

Having worked with a hybrid of git and Google docs to develop a recent RFC,
I'd suggest that there are at least two additional key functions:
* replace [text range] with [new text] (potentially with a coordinated
change several places in the document)
* free text comment

--Kurt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Jan 2021 14:14:24 -0500

Kyle, I did not claim that every conversation should be on the mailing list.
I do claim that all WG conversations need to be visible and 
understandable on the WG email list.  And specifically that anything 
else is disenfranchising part of the community.  Which is what you were 
disagreeing with.

Yours,
Joel

On 1/5/2021 1:07 PM, Kyle Rose wrote:
> On Tue, Jan 5, 2021 at 12:53 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> This conceit has never been true. Conversations happen one-on-one, as 
> well as in person. Not every change a document goes through is discussed 
> on the mailing list, something that was true even in the pre-GitHub era. 
> Editors even make changes unilaterally, without telling anyone! (Crazy, 
> right?)
> 
> Kyle

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 19:16:33 +0000

We had a WG on this, we wrote and published an RFC on this.  Let’s move on to more useful arguments, like requiring all IETF communications to be plaintext email delivered via port 25 to an IPv4 address.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Jan 2021 14:25:37 -0500

As a reasonable compromise, the WG left it to each WG to decide how it 
would work.
As such, we end up having this fight over and over in various working 
groups.
And, equally understandably, some folks want to push the newer approach 
as required for all WGs.  Which causes us to repeat the disucssion on 
the IETF list.

Yours,
Joel

On 1/5/2021 2:16 PM, Salz, Rich wrote:
> We had a WG on this, we wrote and published an RFC on this.  Let’s move 
> on to more useful arguments, like requiring all IETF communications to 
> be plaintext email delivered via port 25 to an IPv4 address.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 19:34:25 +0000

groups.

Oh well, the price of openness is that you have to decide how you want to get things done I guess.

>    And, equally understandably, some folks want to push the newer approach 
    as required for all WGs

I have not seen this.  I have seen some WG's moving to adopt it, but as you point out that's a per-WG approach.  The fact that some people dislike it doesn't raise it to be a general IETF issue.

---

From: Kyle Rose <[email-masked]>
Date: Tue, 5 Jan 2021 14:58:11 -0500

On Tue, Jan 5, 2021 at 1:30 PM Keith Moore <[email-masked]>
wrote:

> one's effectiveness in IETF overall.
>

This is just the last possible gate, "if you never followed the issues or
performed periodic reviews of document revisions prior to those
checkpoints". You can always review documents periodically as new revisions
are posted to the data tracker, and engage on the mailing list for certain
topics. If anything, GitHub keeps noise (nits and whatnot) off the list by
moving it to a tool much better suited to offering and vetting those kinds
of changes.

> Yes, they're useful as last resorts, but the fact that they exist is not
a justification for
> crippling most potential contributors.

The only crippling being proposed here is to prohibit the use of GitHub.
Adding tools that some choose not to take advantage of is not the same
thing, no matter how many times you try to frame it like that. I'd agree
with a softer statement like "The use of GitHub is not an unalloyed good
for every possible contributor", but literally any process change is going
to advantage some in comparison to others. I don't see why that alone
should be the criteria on which this question is decided. Even on the basis
of inclusion, "resistant to change" is not a protected class in any
jurisdiction I know of. I like the current approach of WGs individually
choosing whether or not to use it on the basis of the preference of
participants.

More generally, as much as the content of this list would confuse aliens
about where it lives, this is not the Internet Buggy Whip Task Force: it's
the Internet *Engineering* Task Force. Contributors are (and should be)
overwhelmingly engineers, and so it's natural for them to prefer
engineering tools and workflows. Stop complaining; be an engineer; figure
out the tools; and contribute.

I'm pretty sure I've fully spent my 2¢ now. (Hopefully that UTF-8 character
doesn't confuse anyone's MUA.)

Kyle

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 15:21:03 -0500

On 1/5/21 2:16 PM, Salz, Rich wrote:

> We had a WG on this, we wrote and published an RFC on this.
>
Yes, and now we have enough experience with this experiment to know what 
was good and what was bad about it.   So let's learn from our experience 
and make adjustments based on that experience.  Instead of trying to 
cripple IETF.
>
> Let’s move on to more useful arguments, like requiring all IETF 
> communications to be plaintext email delivered via port 25 to an IPv4 
> address.
>
Plaintext = good, at least until someone solves the problem of a wide 
variety of user agents being able to edit replies to HTML email in a 
uniform fashion.   We've run that experiment for what, 25 years now, and 
though there has been some improvement, overall the results are poor.

Fortunately, MIME emails look the same regardless of whether IPv4, IPv6 
(or X.25, BITNET, DECnet, or uucp, ...) was used to deliver the mail.  
Properly chosen layers are a Good Thing.

Keith

p.s. I consider your message personally insulting and therefore 
inappropriate for IETF.

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 15:30:52 -0500

On 1/5/21 2:58 PM, Kyle Rose wrote:

> On Tue, Jan 5, 2021 at 1:30 PM Keith Moore <[email-masked] 
> This is just the last possible gate, "if you never followed the issues 
> or performed periodic reviews of document revisions prior to those 
> checkpoints". You can always review documents periodically as new 
> revisions are posted to the data tracker, and engage on the mailing 
> list for certain topics. If anything, GitHub keeps noise (nits and 
> whatnot) off the list by moving it to a tool much better suited to 
> offering and vetting those kinds of changes.

No, GitHub unfairly biases against participants who aren't already 
familiar with one particular set of open source tools and culture.

And I'll emphatically disagree with your latter statement also, because 
suggesting diffs of text in any form is only an effective way of 
contributing at a fairly late stage of a document's development.  And I 
would submit that nitpicking text too soon is harmful to producing a 
good document and impedes getting the document done and/or degrades 
document quality.

Having said that I don't disagree that at a late stage of document 
editing, submitting diffs can be a good way of contributing.   But 
expecting people to do this via GitHub is just adding yet another 
barrier to participation for most participants, in addition to sometimes 
making other barriers (like the need to use xml2rfc or some other 
obscure markup language) worse.

> > Yes, they're useful as last resorts, but the fact that they exist is 
> not a justification for
> The only crippling being proposed here is to prohibit the use of 
> GitHub. Adding tools that some choose not to take advantage of is not 
> the same thing, no matter how many times you try to frame it like 
> that. I'd agree with a softer statement like "The use of GitHub is not 
> an unalloyed good for every possible contributor", but literally any 
> process change is going to advantage some in comparison to others. I 
> don't see why that alone should be the criteria on which this question 
> is decided. Even on the basis of inclusion, "resistant to change" is 
> not a protected class in any jurisdiction I know of. I like the 
> current approach of WGs individually choosing whether or not to use it 
> on the basis of the preference of participants.

I'm not sure that even I want to prohibit GitHub entirely, but I think 
it's fair to recognize that it creates some problems and exacerbates 
others.   It's a LOUSY user interface.

We're supposed to be a consensus-making organization, and any 
unnecessary barrier that impairs the ability of some people to 
contribute effectively makes any claims of consensus dubious at best.   
Granted that GitHub isn't the only such barrier, but we were a much 
fairer organization when everyone used email.

>
> More generally, as much as the content of this list would confuse 
> aliens about where it lives, this is not the Internet Buggy Whip Task 
> Force: it's the Internet *Engineering* Task Force. Contributors are 
> (and should be) overwhelmingly engineers, and so it's natural for them 
> to prefer engineering tools and workflows. Stop complaining; be an 
> engineer; figure out the tools; and contribute.
GitHub is not at all representative of a good engineering tool, much 
less a good tool for collaboratively editing text.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 21:24:36 +0000

*   Yes, and now we have enough experience with this experiment to know what was good and what was bad about it.   So let's learn from our experience and make adjustments based on that experience.  Instead of trying to cripple IETF.

Strongly disagree.  But for those writing the report, here’s some anecdata: The HTTPAPI working group would be ineffective if it weren’t working on GitHub. Looking at the membership list, we have key players from all sorts of HTTP API frameworks.

  *   p.s. I consider your message personally insulting and therefore inappropriate for IETF.

Sorry you feel that way; I was commenting on the discussion.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 5 Jan 2021 21:43:34 +0000

Hi Kyle,

> Again, no one in any WG is required to interact with GitHub to contribute.

I don't think the above is true in practice, at least in some
cases. In one case where I'm implementing a draft I've found
the github issue discussion effectively excludes me from
really being part of the discussion.

Github issue discussions do work fine for many people, and
could work fine for me some other time (e.g. if I and others
involved were in similar TZs and online at similar times),
but my experience is that even with the best will in the
world, the split-discussion or exclusionary effect PHB
complained of can and does happen.

I don't think this is only because the github->mail tooling
is worse than useless (for Rich: few mins ago, having been
offline for an hour or two, I got 40 mails for one repo to
which I'm subscribed;-), I think there are problems with
timezones too (hence this mail).

I don't have a good solution for that. Equally, I'm not
asking that we stop with git or github - I just think we
need to do more work to better take into account that the
github issue discussion workflow is not everyone's workflow.

Cheers,
S.

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 16:56:48 -0500

On 1/5/21 4:24 PM, Salz, Rich wrote:

>   * Yes, and now we have enough experience with this experiment to
>     know what was good and what was bad about it.   So let's learn
>     from our experience and make adjustments based on that
>     experience.  Instead of trying to cripple IETF.
>
> Strongly disagree.  But for those writing the report, here’s some 
> anecdata: The HTTPAPI working group would be ineffective if it weren’t 
> working on GitHub. Looking at the membership list, we have key players 
> from all sorts of HTTP API frameworks.
>
handwaving.   Even if I believed you, there's not enough information to 
even evaluate that statement.  For instance, I can't tell whether 
HTTPAPI would be "ineffective" because it wouldn't be excluding so many 
contributors whose opinions would have to be considered, or for some 
other reason.

Keith

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 5 Jan 2021 17:51:45 -0500

On Tue, Jan 05, 2021 at 03:30:52PM -0500, Keith Moore wrote:
> 
> No, GitHub unfairly biases against participants who aren't already familiar
> with one particular set of open source tools and culture.

Some I-D's are written in NROFF, some in XML; does that mean they are
biased against people who don't know NROFF or XML?  Some standards
organizations use Microsoft Office to draft their documents.  Bias!
Unfair!

Hardly.

> Having said that I don't disagree that at a late stage of document editing,
> submitting diffs can be a good way of contributing.   But expecting people
> to do this via GitHub is just adding yet another barrier to participation
> for most participants, in addition to sometimes making other barriers (like
> the need to use xml2rfc or some other obscure markup language) worse.

I'm not aware of any working group where the only way to propose a
change is by submitting a Github pull request.  I would expect
discussions on the mailing list would talk about the changing in
wording of a paragraph or too, or some kind of meta change in English
(let's use the word XXXX instead YYYY everywhere in the document since
it's clearer...).

If large numbers of discussions are happening outside of the mailing
list, whether it be on a Github forum, or on Slack, sure that can be a
problem.  Although that happens when people chat over a restaurant
table back when it was to have face-to-face meetings; so long as such
discussions are confirmed on the mailing list, I don't think we've
ever disallowed discussions of a spec in venues where not everyone was
able to participate --- such as at a restaurant during a face to face
meeting.

To have the document editor use a particular tool, and to allow
*optional* access by those who happen to know that tool?  That seems
completely reasonable to me.  The fact that people who can use a
particular tool to reduce effort required of the document editor seems
to be a *feature*, not a bug.  Does that give them an advantage?
Perhaps, in the same way that a person who is fluent in English has an
advantage to those that don't.  But I don't view that as a fatal bias
in the process because some speak English fluently (or understand
NROFF, or XML, or BNF), and some do not.

> > about where it lives, this is not the Internet Buggy Whip Task Force:
> > it's the Internet *Engineering* Task Force. Contributors are (and should
> > be) overwhelmingly engineers, and so it's natural for them to prefer
> > engineering tools and workflows. Stop complaining; be an engineer;
> > figure out the tools; and contribute.
>
> GitHub is not at all representative of a good engineering tool, much less a
> good tool for collaboratively editing text.

I'd suggest that we leave that decision to the document editors.  If
there are people who are actively choosing GitHub, I'd gently suggest
to you that perhaps they have a difference of opinion than yours; and
we should let the people who are doing the work use what tools they
find most powerful.

Cheers,

					- Ted

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Jan 2021 15:16:12 -0800

Well, there is a way to write RFCs using Word; the hijinks one has to do in order to get ASCII output are a little daunting to me, but I believe they exist.

Go to https://www.rfc-editor.org/pubprocess/tools/ and search for “Microsoft”

Sent from my iPad

> On Jan 5, 2021, at 2:52 PM, Theodore Ts'o <[email-masked]> wrote:
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 18:31:15 -0500

> organizations use Microsoft Office to draft their documents.  Bias!

I would only make that claim if participants were expected, encouraged, 
or could participate more effectively if they submitted contributions in 
nroff, xml, or Word, respectively. But if such contributions were 
expected or favored, I'd make that claim equally for any of those tools.

I certainly would not argue that IETF should encourage WG editors to use 
nroff or that contributions in nroff are in any way appropriate.  Though 
I found nroff reasonably effective in its day, even better than xml2rfc 
in some ways, it's yet another obscure and specialized interface that is 
not particularly well suited to collaboration.

(And even though nroff was perhaps the best tool to write I-Ds for a 
long time, especially for UNIX/Linux users who might already have reason 
to be familiar with the format, I don't actually recall anyone ever 
being expected or encouraged to contribute to a discussion about a 
document using nroff.)

> able to participate --- such as at a restaurant during a face to face
Right.   And I don't think that occasionally working out tricky problems 
on the back of a napkin (or on a laptop) in a restaurant or bar is a Bad 
Thing, as long as it's subject to review on a mailing list.  But we have 
had cases in which participants were effectively excluded in various 
ways - such as by holding lots of interim meetings (f2f or virtual) such 
that participation was effectively limited to people paid by their 
employers to participate. Over-reliance on GitHub [for example, using it 
as a medium of discussion]  is just another way that capable 
participants can be effectively excluded.
> to be a *feature*, not a bug.
Yes it does "seem" like that, and probably works that way in practice, 
so long as it happens rarely enough that it doesn't effectively limit 
participation - reducing the people "in the loop" so to speak to those 
who use that particular tool.
> Does that give them an advantage?
Interesting analogy.   But while we've proven for decades that we can 
work effectively without github, I'm not sure we've figured out how to 
collaborate globally without a common language.  Of course discussions 
do occur in languages other than English, but I've rarely seen mailing 
list discussions in languages other than English.

(I do think it's unfortunate that non-English speakers are at somewhat 
of a disadvantage in IETF.   But one person who was not a native English 
speaker said to me "Using English is a lot like using a standard 
protocol".   Who knows, maybe automatic translation is now good enough 
that we could each subscribe to mailing lists in our preferred 
language.  It would be an interesting experiment.)
> I'd suggest that we leave that decision to the document editors.

Mostly I'm ok with /editors/ using whatever tools they mutually agree 
on, as long as this doesn't effectively exclude some people from being 
editors.  As long as the editors are reasonably flexible in what 
arrangements they'll except it probably works out ok.  (My guess is that 
the choice of editing/collaboration tools won't be as contentious as the 
prose.)

My issue is mostly with the editors or WGs encouraging ordinary 
participants to use tools that effectively limit participation.

To take a step back:  For literally decades I've wondered: How can IETF 
reduce barriers to participation?    When I first started in IETF the 
biggest barrier to participation was the need to have access to email 
and the cost of occasional travel to meetings (you could participate 
effectively without actually attending, but it really helped to have met 
people in person at least once).   Over the years I've seen participants 
expected to jump through more and more hoops, and overcome more and more 
barriers, in order to participate effectively: Higher meeting fees 
(until 2020's virtual meetings and fee waivers [thanks!], but now 
timezones are actually a bigger barrier); HTML emails making annotated 
replies harder (sigh); many new constraints imposed on drafts by the 
submission tool (some of them previously enforced by hard working 
humans); xml2rfc (which if not absolutely required is still often 
expected); the language police; and now github.  Most of these seemed 
like Good Ideas at the time, I don't think any of them were originally 
malicious in intent.   But together it appears MUCH more difficult to 
participate in IETF now than ever in its history.   And while I want to 
acknowledge the hard work that many have put in for decades to lower 
these barriers (I remember when there were NO remote participation 
options though occasionally there would be a speaker in a WG meeting via 
a very expensive international cell phone call); to me that seems like 
despite all that work, and despite all of the amazing advances in 
technology, the situation has still worsened considerably.

I keep wanting to find ways to let people contribute in the ways that 
are most natural to them, using tools that are familiar to them, or at 
least something close to that.

Keith

---

From: avri doria <[email-masked]>
Date: Tue, 5 Jan 2021 18:36:40 -0500

hi,

but still no way to export one from Drive?

speaking of cooperative work environments.

avri

On 2021-01-05 6:16 p.m., Fred Baker wrote:
> Well, there is a way to write RFCs using Word; the hijinks one has to 
> do in order to get ASCII output are a little daunting to me, but I 
> believe they exist.
>
>>> familiar
>>> editing,
>>>> aliens
>>> less a

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jan 2021 18:47:16 -0500

> github issue discussion workflow is not everyone's workflow.

Right.  And, while both have been said a little differently
before (in this threat and in the discussion leading to RFC
8875, let me add two comments to Stephen's:
  
(1) At least for someone with a moderate level of skill (I can't
speak for those with high levels of skill) active github
discussions, especially tracker-type ones, are far easier to
follow if one is doing so more or less continuously than they
are for someone who is looking in much less frequently.  For
better or worse, when email shifts from fewer messages in which
people are listening carefully to each other to rapid
turnarounds of often short and repetitive messages with signs of
increasing tempers and frustration, email gets very hard to
follow too.  However the email usually still seems easier to get
the gist of what is going on by sampling a stream of messages
than trying to decode the history of github discussions and
changes.   I don't know whether 24 messages on this theme in a
tad over six hours is an illustration of anything.

(2) There is a risk in the IETF process (and many like it) of
reaching consensus by some core group (who basically agree
within the group) driving everyone else off.  A group that
agrees on everything but small details, and maybe on those, can
be extremely efficient.  After all, controversies take time to
resolve and the resolution process may not be efficient at all.
But one that gets that efficiency by excluding (even if
completely unintentionally or by choices of style, tools, and
meetings and real-time communications over working
asynchronously is often not, over time, doing the IETF or the
Internet any favors.

    john

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jan 2021 18:57:24 -0500

(top post)

Ted,

I agree with all of this as long as github (or whatever) is a
tool for document editors to do their work and as long as all of
the substantive [1] decisions that inform that work are
documented and, as needed, debated, on the relevant mailing
list.  I am almost certainly not speaking for those who are more
convinced that github is a wonder and efficient tool when I
suggest that we cross some very unfortunate boundary when what
appears on a mailing list is equivalent to "anyone who does not
agree with the reasoning and conclusions reached in XYZ needed
to speak up".  In that regard, it makes no difference whether
"XYZ" is github, "our last interim meeting in a timezone that
was inconvenient for some readers", or something else -- the
effect is exclusionary and makes claims of consensus far more
dubious.

    john

[1] It has been the practice of many WGs and document editors
over the years that suggestions that are purely editorial in
nature can be made by off-list communication with the editor(s).
Using github or, for that matter, smoke signals for similar
input does not seem harmful as long as those editors are
comfortable with it.

--On Tuesday, January 5, 2021 17:51 -0500 Theodore Ts'o
<[email-masked]> wrote:

>> No, GitHub unfairly biases against participants who aren't
>> already familiar with one particular set of open source tools
>> and culture.
> 
> Some I-D's are written in NROFF, some in XML; does that mean
> they are biased against people who don't know NROFF or XML?
> Some standards organizations use Microsoft Office to draft
> their documents.  Bias! Unfair!
> 
> Hardly.
> 
>> Having said that I don't disagree that at a late stage of
>> document editing, submitting diffs can be a good way of
>> contributing.   But expecting people to do this via GitHub
>> is just adding yet another barrier to participation for most
>> participants, in addition to sometimes making other barriers
>> (like the need to use xml2rfc or some other obscure markup
>> language) worse.
> 
> I'm not aware of any working group where the only way to
> propose a change is by submitting a Github pull request.  I
> would expect discussions on the mailing list would talk about
> the changing in wording of a paragraph or too, or some kind of
> meta change in English (let's use the word XXXX instead YYYY
> everywhere in the document since it's clearer...).
> 
> If large numbers of discussions are happening outside of the
> mailing list, whether it be on a Github forum, or on Slack,
> sure that can be a problem.  Although that happens when people
> chat over a restaurant table back when it was to have
> face-to-face meetings; so long as such discussions are
> confirmed on the mailing list, I don't think we've ever
> disallowed discussions of a spec in venues where not everyone
> was able to participate --- such as at a restaurant during a
> face to face meeting.
> 
> *optional* access by those who happen to know that tool?  That
> seems completely reasonable to me.  The fact that people who
> can use a particular tool to reduce effort required of the
> document editor seems to be a *feature*, not a bug.  Does that
> give them an advantage? Perhaps, in the same way that a person
> who is fluent in English has an advantage to those that don't.
> But I don't view that as a fatal bias in the process because
> some speak English fluently (or understand NROFF, or XML, or
> BNF), and some do not.
> 
>> > More generally, as much as the content of this list would
>> > confuse aliens about where it lives, this is not the
>> > Internet Buggy Whip Task Force: it's the Internet
>> > *Engineering* Task Force. Contributors are (and should be)
>> > overwhelmingly engineers, and so it's natural for them to
>> > prefer engineering tools and workflows. Stop complaining;
>> > be an engineer; figure out the tools; and contribute.
>> 
>> GitHub is not at all representative of a good engineering
>> tool, much less a good tool for collaboratively editing text.
> 
> I'd suggest that we leave that decision to the document
> editors.  If there are people who are actively choosing
> GitHub, I'd gently suggest to you that perhaps they have a
> difference of opinion than yours; and we should let the people
> who are doing the work use what tools they find most powerful.

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Jan 2021 16:01:13 -0800

Sent from my iPad

> On Jan 5, 2021, at 3:32 PM, Keith Moore <[email-masked]> wrote:
> 
> don't actually recall anyone ever being expected or encouraged to contribute to a discussion about a document using nroff.)

I think that’s the key point. AT the point where anyone was discussing documents, they were ASCII, regardless of the methodology used in creating them.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Jan 2021 11:05:33 +1100

> On 6 Jan 2021, at 10:57 am, John C Klensin <[email-masked]> wrote:
...
> I suggest that we cross some very unfortunate boundary when what

I think the same could be said about decisions that are made on obscure mailing lists -- many developers refuse to subscribe to them now because of their awful usability problems.

--
Mark Nottingham   https://www.mnot.net/

---

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jan 2021 19:16:30 -0500

--On Wednesday, January 6, 2021 11:05 +1100 Mark Nottingham
<[email-masked]> wrote:

>> I suggest that we cross some very unfortunate boundary when
>> what appears on a mailing list is equivalent to "anyone who
>> does not agree with the reasoning and conclusions reached in
>> XYZ needed to speak up".  In that regard, it makes no
>> difference whether "XYZ" is github, "our last interim meeting
>> in a timezone that was inconvenient for some readers", or
>> something else -- the effect is exclusionary and makes claims
>> of consensus far more dubious.
> 
> I think the same could be said about decisions that are made
> on obscure mailing lists -- many developers refuse to
> subscribe to them now because of their awful usability
> problems.

I tend to agree.   FWIW, note the relationships between that
observation about obscure mailing lists and my December 27
posting about "Fundamental changes in IETF discussions?".

    john

---

From: Keith Moore <[email-masked]>
Date: Tue, 5 Jan 2021 19:21:15 -0500

> I think the same could be said about decisions that are made on obscure mailing lists -- many developers refuse to subscribe to them now because of their awful usability problems.

Not sure what you mean by  "obscure", but I believe that IETF may have 
too many mailing lists, with a bad habit of (whether deliberately or 
not) squelching difficult discussions by spinning up more and more lists 
that people have to then subscribe to and follow.

Also not sure which "awful usability problems" you're referring to, 
because some people seem to think that even using email at all (and 
sifting through the spam and the scams and the automatically generated 
messages from other tools, and perhaps also just reading traffic from 
other contributors) are impositions.   But I will certainly agree that 
having to subscribe to lots of new mailing lists makes for a poor user 
interface.

Keith

p.s. 20+ ago I decided to subscribe to each IETF list using a unique 
email address so that I could route each list's traffic to its own 
subfolder.   But after IETF lists started to "moderate" messages from 
non-subscribers, I had to either change my From address for each list 
(which I didn't want to do because I wanted that address to be used only 
for list traffic and not private replies), or subscribe twice to each 
list, once using the unique address and another time (with email turned 
off) from my usual email address.

I now think that it might have been a mistake to put each list in a 
separate folder, because it seems to be more difficult to keep up with 
multiple lists that way.   This might be because the number of folders 
is more than will fit in the height of a full-screen window, and I 
haven't found a mail user agent that lets me effectively keep track of 
not only which folders have new messages, but which folders haven't been 
read in awhile.   (MUA user interfaces seem to have stagnated in the 
late 1990s, with many products actually getting worse since then.)

I've tried using the IMAP interface to read multiple lists without 
having to subscribe to them, but after investing multiple hours on 
multiple occasions, never got it to work well.

Vaguely speaking I get the impression that we're often drowning in 
"solutions" (not just in IETF), and what we need might not be /more/ 
solutions so much as /simpler/ ones.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Jan 2021 00:46:12 -0500

> make it more accessible, not to prohibit it.

Since the Open Meeting requires a Lisp Machine to run (!) I was not
suggesting that we adopt that. What I said is that I am starting to build a
tool for my own purposes, namely the ability to hold end-to-end encrypted
collaborations in environments that require a higher level of security
including classified and SCI environments. I am not aware of github being
used for those purposes.

My problem with using git/github as a process driven collaboration tool is
that github is designed to perform an entirely different task. So the
effect is like someone telling you to use a screwdriver as a hammer and
ignoring the complaints from people pointing out its a bad match. That
doesn't mean it isn't the best tool available at the moment but it is not a
good tool for that purpose because thats not what it is for.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jan 2021 07:56:26 +0000

The good thing is that there is no real problem here. In most working groups a limited number of people actively participate. Those people know how to contribute. For those who just browse through groups from time to time it got more difficult to see where the center of attention currently is. While participation on IETF mailing lists is free of charge, it still consumes a fair amount of time.

Ciao
Hannes

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Theodore Ts'o
Sent: Tuesday, January 5, 2021 11:52 PM
To: Keith Moore <[email-masked]>
Cc: IETF Discussion Mailing List <[email-masked]>
Subject: Re: Old directions in social media.

> familiar with one particular set of open source tools and culture.

Some I-D's are written in NROFF, some in XML; does that mean they are biased against people who don't know NROFF or XML?  Some standards organizations use Microsoft Office to draft their documents.  Bias!
Unfair!

Hardly.

> editing, submitting diffs can be a good way of contributing.ï¿½ï¿½ But
> barrier to participation for most participants, in addition to
> sometimes making other barriers (like the need to use xml2rfc or some other obscure markup language) worse.

I'm not aware of any working group where the only way to propose a change is by submitting a Github pull request.  I would expect discussions on the mailing list would talk about the changing in wording of a paragraph or too, or some kind of meta change in English (let's use the word XXXX instead YYYY everywhere in the document since it's clearer...).

If large numbers of discussions are happening outside of the mailing list, whether it be on a Github forum, or on Slack, sure that can be a problem.  Although that happens when people chat over a restaurant table back when it was to have face-to-face meetings; so long as such discussions are confirmed on the mailing list, I don't think we've ever disallowed discussions of a spec in venues where not everyone was able to participate --- such as at a restaurant during a face to face meeting.

To have the document editor use a particular tool, and to allow
*optional* access by those who happen to know that tool?  That seems completely reasonable to me.  The fact that people who can use a particular tool to reduce effort required of the document editor seems to be a *feature*, not a bug.  Does that give them an advantage?
Perhaps, in the same way that a person who is fluent in English has an advantage to those that don't.  But I don't view that as a fatal bias in the process because some speak English fluently (or understand NROFF, or XML, or BNF), and some do not.

> > aliens about where it lives, this is not the Internet Buggy Whip Task Force:

I'd suggest that we leave that decision to the document editors.  If there are people who are actively choosing GitHub, I'd gently suggest to you that perhaps they have a difference of opinion than yours; and we should let the people who are doing the work use what tools they find most powerful.

Cheers,

- Ted

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 07:58:05 -0500

On 1/6/21 2:56 AM, Hannes Tschofenig wrote:

> The good thing is that there is no real problem here. In most working groups a limited number of people actively participate. Those people know how to contribute. For those who just browse through groups from time to time it got more difficult to see where the center of attention currently is.

I would claim that what you describe *is* a real problem.   IETF works 
best when it benefits from a wide range of input, including "cross-area" 
input and input from generalists.   When working groups consist of a 
small number of people who do whatever they want in their narrow areas 
of concern, groups have a greater tendency to work at cross-purposes 
with one another.

And I would claim that we've been seeing the unfortunate results of that 
for many years now, so that instead of resolving tussles we encourage 
them, and we produce more and more standards that lack coherence with 
one another.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 07:13:02 -0800

On 1/6/21 4:58 AM, Keith Moore wrote:
>> The good thing is that there is no real problem here. In most working 
>> groups a limited number of people actively participate. Those people 
>> know how to contribute. For those who just browse through groups from 
>> time to time it got more difficult to see where the center of 
>> attention currently is.
>
> best when it benefits from a wide range of input, including 
> "cross-area" input and input from generalists.   When working groups 
> consist of a small number of people who do whatever they want in their 
> narrow areas of concern, groups have a greater tendency to work at 
> cross-purposes with one another.
>
I disagree. Most of the time the soi-disant "generalilsts" are just 
self-aggrandizing and like to hear themselves speak. I remember when we 
were creating the DKIM working group we had a whole bunch of them and 
their "input" ended up contributing nothing at all other than delay.

Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 10:24:00 -0500

On 1/6/21 10:13 AM, Michael Thomas wrote:

> self-aggrandizing and like to hear themselves speak. I remember when 
> we were creating the DKIM working group we had a whole bunch of them 
> and their "input" ended up contributing nothing at all other than delay. 

There are also plenty of people in IETF, who aren't generalists, who 
like to hear themselves speak.

DKIM, or anything that remotely had to do with thwarting spam, may have 
been atypical.   So many people are burned by spam and have naive ideas 
about how to address it, that such groups attract a lot of contributors 
with widely varying levels of expertise. And unfortunately, there's a 
broad tendency within IETF to disregard the input of anyone and everyone 
who wants to address that problem and has even a slightly different 
idea.   But I don't think such groups are representative of the whole.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 07:28:00 -0800

On 1/6/21 7:24 AM, Keith Moore wrote:
> DKIM, or anything that remotely had to do with thwarting spam, may 
> have been atypical.   So many people are burned by spam and have naive 
> ideas about how to address it, that such groups attract a lot of 
> contributors with widely varying levels of expertise. And 
> unfortunately, there's a broad tendency within IETF to disregard the 
> input of anyone and everyone who wants to address that problem and has 
> even a slightly different idea.   But I don't think such groups are 
> representative of the whole.
>
Fortunately, I knitted.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jan 2021 15:56:08 +0000

Keith,

for cross area reviews all you need are IETF drafts. I doubt that reviewers are interested in digging through the Github issues, PRs, and mailing list discussions.

Regarding "resolving tussles we encourage them, and we produce more and more standards that lack coherence with one another." Note my mail on that topic, see https://mailarchive.ietf.org/arch/msg/ietf/YWTxZEik6gqGod9d5KbAdqNbh3g/
Moving all discussions from Github to the mailing list will have no impact on this issue.

Ciao
Hannes

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Keith Moore
Sent: Wednesday, January 6, 2021 1:58 PM
To: [email-masked]
Subject: Re: Old directions in social media.

> The good thing is that there is no real problem here. In most working groups a limited number of people actively participate. Those people know how to contribute. For those who just browse through…

I would claim that what you describe *is* a real problem.   IETF works best when it benefits from a wide range of input, including "cross-area"
input and input from generalists.   When working groups consist of a small number of people who do whatever they want in their narrow areas of concern, groups have a greater tendency to work at cross-purposes with one another.

And I would claim that we've been seeing the unfortunate results of that for many years now, so that instead of resolving tussles we encourage them, and we produce more and more standards that lack coherence with one another.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 11:42:13 -0500

> for cross area reviews all you need are IETF drafts. I doubt that reviewers are interested in digging through the Github issues, PRs, and mailing list discussions.

Well, the more working groups spread their discussions over various 
media, the harder it is for anyone not really tied up with the WG to 
contribute usefully.   Some people may consider that a feature; I don't.

And in general, the later those who are not "in the loop" submit their 
input, the less effective that input is.   Last Calls are the worst 
case, but reviewing the drafts are only slightly better.   Really you 
need to get the broad input very early in the WG discussion.   But you 
also need people with broader interests watching the WG throughout its 
life to make sure their input is taken into consideration.

> Regarding "resolving tussles we encourage them, and we produce more and more standards that lack coherence with one another." Note my mail on that topic, seehttps://mailarchive.ietf.org/arch/msg/ietf/YWTxZEik6gqGod9d5KbAdqNbh3g/

FWIW I disagreed with you about that.   I didn't post my disagreement 
because I thought any ensuing discussion would probably rathole.   But 
briefly: while I think fragmentation in IETF is a problem with respect 
to IoT and most other topics, for the specific area of IoT IETF has much 
worse problems - basically a general lack of clue and a lot of 
widespread assumptions about IoT in IETF which basically aren't true.   
So IMO IETF is not currently in a great position to have a positive 
effect on IoT, and I think it will take a lot of work to get there if 
the organization even wants to try.

Keith

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 06 Jan 2021 09:56:39 -0800

Keith Moore <[email-masked]> writes:

>     I think the same could be said about decisions that are made on
>     obscure mailing lists -- many developers refuse to subscribe to
>     them now because of their awful usability problems.

> And Keith wrote:
> because some people seem to think that even using email at all ([...])
> are impositions.??

We (anyone that's participated in the IETF for a long or potentially
short time) have learned how to use email well.  But it is a skill, and
it's a skill that a lot of the younger generations really don't want to
learn.  It's not easy to edit text, quote people properly, not top-post,
not mess up fonts and markups, not realize that some readers don't
support fonts and markups, quote text in a readable way, etc.  Editing
straight ASCII or UTF-8 is a skill that is absolutely possible for "us"
today because we've both developed it and use editors that help us.

But the younger generations are writing reports and documents only using
online collaborative editing, don't use email at all, and find they're
very productive under github issue trackers and slack etc.  I mentor a
fairly large high school software team.  They use no email (sticking to
slack and github) and have zero desire to start.  Because it's a skill
they don't have, they don't feel they need and thus its a skill they
actively don't want.  I've given them many mini-lectures that when they
get to a work place they'll likely be forced to use email.  But, even
many work environments are holding a multitude of their discussions over
some channel-based discussion platform instead.

FWIW, I hate issue trackers because of their lack of threaded
conversations (though almost no MUAs support that now too), because it's
impossible to know where to start reading again when I've missed a day,
etc.  I do love the attached labeling, assignments, tagging and status
metadata, but the discussion forum doesn't work for me.  But I
absolutely recognize that many others in the world don't have *my*
issues with it.

We can absolutely set the minimum entrance requirements to be able to
participate in the IETF, either globally or per-wg.  But if its not
inclusive as widely as possible we lose opinions from talented subject
matter experts.  Given the aging population of the core IETF
participants, we're headed for a cliff if we don't find a common middle
ground that works for the largest intersection of the participants that
we can attract.  That doesn't mean giving up, but it does mean finding a
reasonable consensus.  Likely rough.

-- 
Wes Hardaker
USC/ISI

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Jan 2021 13:07:46 -0500

What Wes said.
Frankly, email got put in the ICU by Outlook and then killed when Apple Mail
replicated all the mis-features, rather than mitigated them.
People in the IETF couldn't even be bothered to get "format=flowed"
marked right on text/plain.
I, like Keith, I think, wish text/rich had succeeded.

I'm not convinced that teens don't want email, but rather that they don't want Outlook.
But, I don't have the same context that Wes has: my context is through my
teenager and his friends.

I have used git (and CVS before) to manage Internet drafts, and migrated to
github issues only in the last two years.

Frankly, the "grey beards" [I'm literally one now] who say that they can't
learn github are really telling me that they are too old for "running code",
and my message is: retire.
Sorry to be mean, but you are telling me that you can't learn new tricks.

I know (and collaborate with) a number of very grey beards who are almost 2x
my age and they learn new stuff all the time.

I use github extensively *as a design team*.
I don't really want the entire WG to use it to be honest.

This recurring thread from the same people year after year is tiresome, and I
read Wes' message only because it was Wes.

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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 6 Jan 2021 18:18:37 +0000

I’m not really wanting to get dragged into this debate … but I think that it might be interesting to try and objectively compare the quality of the documents produced by WGs making use of github vs those just using email.

One swallow does not a summer make, but I note that the 4 QUIC documents that are in IESG review all seem to be exceptionally polished and well written, and I understand that the QUIC WG has a strong Github based editing process.  Of course, there could be many factors as to why this is (e.g., maybe the editors are native English speakers, these documents probably have had more review and discussion) but it also seems plausible that easier collaborative editing/updates might be a factor in the high quality output from the WG.

And obviously, this doesn’t mean that other WGs don’t also produce high quality output …

Rob

From: ietf <[email-masked]> On Behalf Of Keith Moore
Sent: 05 January 2021 16:43
To: [email-masked]
Subject: Re: Old directions in social media.

+1

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 13:20:04 -0500

> Sorry to be mean, but you are telling me that you can't learn new tricks.

It's not the lack of willingness to learn new tools that's the problem, 
it's the lack of willingness to use tools which are extremely 
dysfunctional and which marginalize large numbers of participants, when 
we have much better tools already.

Granted, email is not as usable as it used to be.  Plain text email now 
looks like a virtue (in hindsight) because there were a lot fewer things 
to break.

Keith

p.s. I find ageism completely inappropriate, even (or perhaps 
especially) when it comes from people who believe they are old enough to 
be inappropriate.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 10:27:51 -0800

On 1/6/21 10:18 AM, Rob Wilton (rwilton) wrote:
>
> I’m not really wanting to get dragged into this debate … but I think 
> that it might be interesting to try and objectively compare the 
> quality of the documents produced by WGs making use of github vs those 
> just using email.
>
> One swallow does not a summer make, but I note that the 4 QUIC 
> documents that are in IESG review all seem to be exceptionally 
> polished and well written, and I understand that the QUIC WG has a 
> strong Github based editing process. Of course, there could be many 
> factors as to why this is (e.g., maybe the editors are native English 
> speakers, these documents probably have had more review and 
> discussion) but it also seems plausible that easier collaborative 
> editing/updates might be a factor in the high quality output from the WG.
>
>
I'm fairly certain that it has far more to do with who is 
authoring/editing the documents than any tools. My favorite whipping boy 
rfc 8226 is terrible and woefully underspecified, and when that was 
pointed out in last call, it got aggressive push back. Tools are not 
going to change that sort of problem. What we'd need is AI's that can 
emulate the normative language and poke holes in it. Sometimes the I's 
are up to the task but too often they are not, or are ignored.

Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 13:34:58 -0500

On 1/6/21 1:18 PM, Rob Wilton (rwilton) wrote:

> but I note that the 4 QUIC documents that are in IESG review all seem 
> to be exceptionally polished and well written, and I understand that 
> the QUIC WG has a strong Github based editing process

I guess I'm wondering: what are the actual virtues of github (other than 
that some people are already familiar with it) and is there a way to 
build a tool that has those virtues without so much baggage, with a 
lower barrier to entry, and which is more universally usable?

One virtue appears to be encouraging WG participants to submit concrete 
suggestions for changes in the same format as the document is being 
maintained.

Another virtue might be built-in support for issue tracking.

But mostly, to me, github looks like a huge impediment.  And I use git 
with program source code all the time.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 10:43:41 -0800

On 1/6/21 10:34 AM, Keith Moore wrote:
> I guess I'm wondering: what are the actual virtues of github (other 
> than that some people are already familiar with it) and is there a way 
> to build a tool that has those virtues without so much baggage, with a 
> One virtue appears to be encouraging WG participants to submit 
> concrete suggestions for changes in the same format as the document is 
> being maintained.
>
I have no particular feeling about github one way or another, but 
diffing has always been a problem. Accountability is another problem, 
which is to say "how did this change slip in there?". Source control is 
at its heart about keeping track of who changed what and for what 
reason. For me, it would be really nice to know the progression of DKIM 
from rfc 4871 to STD 76, what changed, and who and why did they do it. 
Source control definitely gives you that, assuming they annotate the 
"why"'s in the checkin notes. That part of the process has tended to be 
pretty opaque in my experience.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jan 2021 18:48:08 +0000

*   I guess I'm wondering: what are the actual virtues of github (other than that some people are already familiar with it)
You brush that aside as if it’s of no consequence. GitHub claims As of January 2020, GitHub reports having over 52 million users and more than 28 million public repositories.  Since we want to engage the open source community, it behooves to make accomodations, rather than try to say “use this, it’s better.” Fortunately, the accommodation is something the IETF has already approved, and left use of to individual working groups.

  *   But mostly, to me, github looks like a huge impediment

By my reckoning, you’re in the rough here.  Even if the entire IETF community agreed with you – and they don’t – the percentage would still be a round-off error and approximates to zero.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 6 Jan 2021 10:50:37 -0800

I'd like to see the IETF LLC fund some development of enterprise github.ietf.org to make it work better.
Just off the top ...
An enterprise license so it could be customized.
Fix the default GFM so it could easily be used to produce xml2rfcv3
With custom diff appropriate.
Default actions for building PDF, HTML, text views
Tie in with DataTracker and appropriate authentication....
Integrate with email and wg "decisions"
Fix the bugs in GitHub "discussions" <-> Issues
Integration with meeting tools (agendas, minutes)
Default "Teams" & roles appropriate for WG work rather than software development
Tutorials & written guides for using Git for IETF work
 Regular summaries and insights appropriate for document production
Some way to subscribe to summaries of actions and topics without watching every action on the repo
(maybe a 'significant change' flag that the PR has and must be approved)

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 13:53:15 -0500

On 1/6/21 1:48 PM, Salz, Rich wrote:

>   * I guess I'm wondering: what are the actual virtues of github
>     (other than that some people are already familiar with it)
>
> You brush that aside as if it’s of no consequence. GitHub claims As of 
> January 2020, GitHub reports having over 52 million users**and more 
> than 28 million public repositories.  Since we want to engage the open 
> source community, it behooves to make accomodations, rather than try 
> to say “use this, it’s better.” Fortunately, the accommodation is 
> something the IETF has already approved, and left use of to individual 
> working groups.
>
No it does not, if it comes at a cost of impairing broad participation 
in IETF.
> By my reckoning, you’re in the rough here.  Even if the entire IETF 
> community agreed with you – and they don’t – the percentage would 
> still be a round-off error and approximates to zero.
>
Actually, you're in the rough here.   Several people have expressed 
reservations about github which you disregard with a wave of your hand. 
   But it really doesn't matter, because we're having a discussion not a 
consensus call.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Jan 2021 11:00:08 -0800

> some channel-based discussion platform instead.
I get the impression the reason that the younguns don't use email is the 
same reason they don't use facebook: it's uncool and for old people. The 
one thing email cajoles is some amount of contemplation since it's not 
really interactive, per se. Usenet style threading is sorely missed though.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Jan 2021 19:42:37 +0000

Keith,

let me quickly respond to the first part of your email response.

> Well, the more working groups spread their discussions over various media, the harder it is for anyone not really tied up with the WG to contribute usefully.   Some people may consider that a feature; I don't.

> And in general, the later those who are not "in the loop" submit their input, the less effective that input is.   Last Calls are the worst case, but reviewing the drafts are only slightly better.   Really you need to get the broad input very early in the WG discussion.   But you also
> need people with broader interests watching the WG throughout its life to make sure their input is taken into consideration.

I like your "romantic" view about high-quality reviews: There is this genius sitting someone. Nothing else to do he or she browses through the web and discovers the IETF website with all this interesting content. He or she reads through long email discussions and even longer drafts. Then, some earthshaking revelations are made and feedback is sent to the relevant working groups or draft authors.

Joke aside - my experience with IETF feedback is very different. It is hard work and you cannot wait for a random outsider to provide high-quality feedback. You (as document authors, working group members, working group chair) have to reach out to other communities (like researchers, implementers, the deployment community, etc.). You have to give presentations at conferences and workshops. You have to organize interoperability events. Etc. You have to convince others that the work you are doing is worthwhile their time.

In any case, our two views are just tiny data points on how reviews are done in the IETF and it would be interesting to investigate how we can improve the review process of our specifications. By that I am not talking about having another directorate being forced to review more documents. As you know, I have suggested to use formal methods more extensively during protocol design. I also think more implementation and interop testing would help to improve the quality of the specifications (and to involve others).

Ciao
Hannes

PS: FWIW I agree with you that late reviews are less than ideal for the document authors and for the respective working group. However, doing an early review is pain for reviewers when documents are still inconsistent. Unless reviewers get some reward I doubt they are interested in suffering just for fun.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Jan 2021 16:31:15 -0500

Hannes, I have to disagree about what it takes to participate in 
cross-area discussions.

As an example, I have problems with something currently being discussed 
in the DMM group (whether I am in the rough or the predominating side 
remains to be seen.  That is not the point of this comment.

If I had to go through the discussion on the git issues tracker to 
figure out what was being said and why, it would be MUCH harder to 
appropriately participate in the discussions.

Yours,
Joel

PS: While I do not typically participate in dmm, I do follow it, and am 
at least somewhat knowledgeable about the space.  The ability to follow 
it on the emial list is important to me.

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Jan 2021 16:43:36 -0500

> Joke aside - my experience with IETF feedback is very different. It is hard work and you cannot wait for a random outsider to provide high-quality feedback. You (as document authors, working group…
I certainly agree that we can't just wait for random outsiders to review 
things, and I appreciate the hard work it takes to get wide review.   
But I've also seen high-quality and useful feedback from the extended 
IETF community, and I don't think we should be adopting practices that 
discourage that.
> PS: FWIW I agree with you that late reviews are less than ideal for the document authors and for the respective working group. However, doing an early review is pain for reviewers when documents are still inconsistent.
Some of the early feedback I would not call "review" but something 
closer "feed forward".    WGs and document authors need to understand 
the constraints of the space they are designing for, and input from 
outside the WG core can be very valuable for this and should be encouraged.

Keith

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jan 2021 10:17:26 +0000

Hi Joel,

I fully understand that it is more convenient for you to have everything available in your favorite tool (in this case email).
But consider also what is easier and more efficient for those who actually do the bulk of the work.

Ciao
Hannes

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: Wednesday, January 6, 2021 10:31 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: Old directions in social media.

Hannes, I have to disagree about what it takes to participate in cross-area discussions.

As an example, I have problems with something currently being discussed in the DMM group (whether I am in the rough or the predominating side remains to be seen.  That is not the point of this comment.

If I had to go through the discussion on the git issues tracker to figure out what was being said and why, it would be MUCH harder to appropriately participate in the discussions.

Yours,
Joel

PS: While I do not typically participate in dmm, I do follow it, and am at least somewhat knowledgeable about the space.  The ability to follow it on the emial list is important to me.

On 1/6/2021 10:56 AM, Hannes Tschofenig wrote:
> Regarding "resolving tussles we encourage them, and we produce more
> and more standards that lack coherence with one another." Note my mail
> on that topic, see
> https://mailarchive.ietf.org/arch/msg/ietf/YWTxZEik6gqGod9d5KbAdqNbh3g
> / Moving all discussions from Github to the mailing list will have no
> impact on this issue.
>
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jan 2021 10:30:13 +0000

Hi Keith,

> I certainly agree that we can't just wait for random outsiders to review things, and I appreciate the hard work it takes to get wide review. But I've also seen high-quality and useful feedback from the extended IETF community, and I don't think we should be adopting practices that discourage that.

From your experience, what are these reviews typically based on? Are they based on drafts or something else? If I recall great feedback I received "recently" then the review from Bob Briscoe on the SUIT architecture comes to mind (which happened late in the process based on the draft) and feedback from implementers (which was, of course, also based indirectly on a draft version).

> Some of the early feedback I would not call "review" but something closer "feed forward".    WGs and document authors need to understand the constraints of the space they are designing for, and input from outside the WG core can be very valuable for this and should be encouraged.

This is also an interesting case because it is input (for feed forward, as you call it) that is substantially different from the feedback later in the life of a specification (or set of specifications). In my experience this type of input is given during BOFs, in informal discussions, etc. and is often extremely time consuming for the persons providing the input. What is your experience there?

I am wondering whether the discussion about feedback /  input isn't largely orthogonal from the question what tools (email, Github, Slack, etc.) are being used. Providing input early in the life of a specification has always been a challenge - even before Github was around.

Ciao
Hannes

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 Jan 2021 07:54:32 -0500

> But consider also what is easier and more efficient for those who actually do the bulk of the work.

I am not sure that I agree that "the bulk of the work" is document 
editing.  In my experience a tremendous amount of work is done in 
discussion, because truly understanding what is important to get right 
about a protocol, and truly understanding what the issues are, and truly 
developing an understanding of many participants' points of view - 
seeing things from many different angles - is very hard work.   And that 
hard work is not only done by the document editors or chairs, but often 
by several different active participants in a conversation.

Document editing is indeed difficult work, and I don't wish to discount 
that.   But the (partial) merging of minds is what makes good documents 
possible.

And I also don't think that we should presume that github is more 
efficient, or that it is or should be the tool of choice, for everybody 
who edits I-Ds.   That seems like an undesirable bias for IETF to impose 
should it go down that path.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 Jan 2021 08:20:45 -0500

>  From your experience, what are these reviews typically based on? Are they based on drafts or something else? If I recall great feedback I received "recently" then the review from Bob Briscoe on th…

I think the feedback is as likely to be based on f2f conversations and 
email conversations and also WG presentations, in addition to drafts.   
More realistically, as work progresses, early feedback is more likely to 
be based on such conversations, and later feedback more likely to be 
based on drafts.  But conversations play a large role even fairly late 
in the process.

(I often find the WG presentation materials to be MUCH better at 
facilitating useful conversations than the drafts, even if I find time 
spent "presenting" those materials to be largely wasted. Being able to 
read those materials without sitting through the presentations is 
great.  Being able to have real time conversations about those materials 
is also great if people have read those materials in advance.)

I think it's worth pointing out that reviewing documents is itself 
difficult and tedious work, and often it's easier to build consensus 
around design decisions before picking apart and wordsmithing the 
documents.  But it's also the case that people usually won't take a 
proposal seriously until there's a reasonably complete draft of it.   So 
you write a draft for people to attack (which should be complete enough 
to look credible but still leave some decisions for people to haggle 
over), then you have conversations, then you rewrite the draft - often 
substantially and multiple times, until finally you converge enough to 
do wordsmithing.   And it's in this last stage that I see github as 
being a useful though still really awkward tool.  But the conversations 
continue throughout.

Looking at this now, I wonder if one of the problems with our typical 
process is that we insist on having even the earliest proposals look 
like an RFC, as opposed to say, a set of bullet points.

> This is also an interesting case because it is input (for feed forward, as you call it) that is substantially different from the feedback later in the life of a specification (or set of specificati…

In my experience the feedback occurs not so much in BOFs (though this 
does happen) as in informal discussions and WG discussions.

IMO most constructive feedback, regardless of when it's given or the 
form it takes, is extremely time consuming for the persons providing the 
input.    But the hardest part of the work isn't in writing the words; 
it's in understanding what's really important to different people with 
different experiences, different points of view, different ways of 
expressing themselves.

> I am wondering whether the discussion about feedback /  input isn't largely orthogonal from the question what tools (email, Github, Slack, etc.) are being used. Providing input early in the life of…

I think the tools have an effect at every stage.    Maybe no tool will 
make the process of understanding easier, but poor tools can certainly 
make the process more difficult.

But I also think that the work habits we have, many of them well 
entrenched in IETF culture, may also be making the process much more 
difficult than it needs to be.

Keith

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2021 10:47:22 -0500

I do not see how your reply addressess the question of participating in 
effective cross-area review.

Separatately, the question of "those who actually do the bulk of the 
work" seems misleading.

I at least, I I think all the participants, understand that author teams 
or design teams will usee whatever tools they want.  The issue is what 
is used for WG discussion and resolution of issues.  All WG discussion 
of issues.

Yours,
Joel

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 7 Jan 2021 17:35:52 +0100 (CET)

>     Il 06/01/2021 00:31 Keith Moore <[email-masked]> ha scritto:
> 
>     But together it appears MUCH more difficult to participate in IETF now than ever in its history.   And while I want to acknowledge the hard work that many have put in for decades to lower these barriers (I remember when there were NO remote participation options though occasionally there would be a speaker in a WG meeting via a very expensive international cell phone call); to me that seems like despite all that work, and despite all of the amazing advances in technology, the situation has still worsened considerably. 
> 
As a side note on this point, I suspect that today's general difficulty in participating meaningfully in the creation and standardization of new Internet technology is mostly not due to the change in discussion instruments, but to the extreme specialization of today's Internet engineering tasks, as a consequence of its own technical development and of its massive growth.

When I got my first Internet access as a student in the mid 90's, you could very easily learn some simple tools and languages and start building your own stuff - and that was the Internet's magic. Just a few weeks after getting connected, I was already able to put up my first personal website. For a while, you could build and deploy a state-of-the-art website just by installing a single application (Apache 1.0) and learning a single spec (RFC 1866). Today it takes at least half a dozen of different job descriptions relying on hundreds of specifications to build one, unless you want to rely on pre-cooked stuff - so you do that. Almost all engineers just use tools, applications and libraries that other people implemented, and never come in touch with the actual standards except for, maybe, a tiny subset of them.

So, of course today the discussions on IETF WG mailing lists are often impossible to understand even for people that are considered to be expert engineers on that topic. But that's not a tooling issue.

--

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jan 2021 16:43:02 +0000

Hi Joel,

Everyone wants to have more effective reviews. We have an agreement there.

Where it gets tricky is how to accomplish this (ignoring what "effective" precisely means).

The discussion moved into "I want to use my tools and not yours". There is no middle ground. You want to have everyone use email so you can scan through discussions more easily. Others, who have been working on implementations are familiar with Git, and they seem to feel that they are most efficient using those tools.

Regarding "those who actually do the bulk of the work". There are lots of steps to get to widespread deployment of technology. Writing the spec is only a small part of the job. Producing implementations of the specs, and deploying them is a big part of it. Sometimes you can observe that people write specifications and then they run away because they believe the work is done. It is often more exciting to work on the latest thingy rather than doing the other 20% of the work that take 80% of the time.

Those folks in the community who do also the last 20% should get credit and if we can make their life easier I believe we will get not only more done but we will also be more successful as an organization.

You aware of all of this given how long you have been around in the IETF already.

Ciao
Hannes

-----Original Message-----
From: Joel M. Halpern <[email-masked]>
Sent: Thursday, January 7, 2021 4:47 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: Old directions in social media.

I do not see how your reply addressess the question of participating in effective cross-area review.

Separatately, the question of "those who actually do the bulk of the work" seems misleading.

I at least, I I think all the participants, understand that author teams or design teams will usee whatever tools they want.  The issue is what is used for WG discussion and resolution of issues.  All WG discussion of issues.

Yours,
Joel

On 1/7/2021 5:17 AM, Hannes Tschofenig wrote:
>> and more standards that lack coherence with one another." Note my
>> mail on that topic, see
>> https://mailarchive.ietf.org/arch/msg/ietf/YWTxZEik6gqGod9d5KbAdqNbh3
>> g / Moving all discussions from Github to the mailing list will have
>> no impact on this issue.
>>
>> Ciao
>> Hannes
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2021 11:57:38 -0500

I would like to find a middle ground.  I assume, from your phrasing, 
that you consider that the suggestions I have made for such do not 
constitute a viable middle ground.  I have not seen counter-suggestions 
for a middle ground.  (Maybe I missed them.  If so, I apologize for 
misrepresentation.) Some folks have suggested to me off list that there 
does not exist a viable middle ground.  I hope that is not the case.

Yours,
Joel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Jan 2021 09:03:05 -0800

> The discussion moved into "I want to use my tools and not yours". There is no middle ground. You want to have everyone use email so you can scan through discussions more easily. Others, who have be…
As I said elsewhere, the problem as I see it with the way that most 
working groups I have been a part of is that the actual editing of the 
document is not very transparent and often just the author's take on 
consensus which can obviously be self-serving if they want to be. Having 
an audit trail of when and why changes were made would be a definite 
move in the right direction. It would also give the chairs an easy way 
to cross check changes where consensus was dubious or not achieved.

Pull requests seem a little baroque, but they are baroque in git too, 
imo. But there is no good way to formally ask that a specific change be 
made in a specific part of the document. That tends to get lost in the 
back and forth of mailing list traffic. The problem with a pull request 
per se is that if it's not a nit it needs to be determined if it has 
consensus. That's not a problem with the normal use of git, but is 
problematic with consensus driven IETF: authors shouldn't be the ones 
arbitrarily calling consensus, though that is often the case by default.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 7 Jan 2021 17:24:43 +0000

I completely agree with you, Mike.

Lack of transparency in the decision making process is a problem and pre-dates the use of Github. I am not sure whether our use of Github improved it or made it worse. Chairs need to be aware of those problems and alert. I know that this is difficult because it puts a lot on the shoulders of the WG chairs, and often they are conflicted when half of the active working group members work for the same company.

This discussion is a bit tricky because we all have specific problems in mind but nobody wants to mention any specific cases.

Ciao
Hannes

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Michael Thomas
Sent: Thursday, January 7, 2021 6:03 PM
To: [email-masked]
Subject: Re: Old directions in social media.

> The discussion moved into "I want to use my tools and not yours". There is no middle ground. You want to have everyone use email so you can scan through discussions more easily. Others, who have be…
As I said elsewhere, the problem as I see it with the way that most working groups I have been a part of is that the actual editing of the document is not very transparent and often just the author's take on consensus which can obviously be self-serving if they want to be. Having an audit trail of when and why changes were made would be a definite move in the right direction. It would also give the chairs an easy way to cross check changes where consensus was dubious or not achieved.

Pull requests seem a little baroque, but they are baroque in git too, imo. But there is no good way to formally ask that a specific change be made in a specific part of the document. That tends to get lost in the back and forth of mailing list traffic. The problem with a pull request per se is that if it's not a nit it needs to be determined if it has consensus. That's not a problem with the normal use of git, but is problematic with consensus driven IETF: authors shouldn't be the ones arbitrarily calling consensus, though that is often the case by default.

Mike

---

From: Kyle Rose <[email-masked]>
Date: Thu, 7 Jan 2021 12:27:14 -0500

On Thu, Jan 7, 2021 at 12:03 PM Michael Thomas <[email-masked]> wrote:

> The problem with a pull request
> consensus

This is unrealistic, and is not in fact how things actually work. In
general, very minor changes employ a form of acclimation: unless someone
objects, they are assumed to have rough consensus if the editors apply
them. If every single change regardless of size needed a consensus call, no
document would ever get finished. In reality, only major proposed changes
get this kind of formal treatment.
Kyle

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jan 2021 12:31:24 -0500

On Wed, Jan 6, 2021 at 1:48 PM Salz, Rich <rsalz=[email-masked]>
wrote:

>
>    - I guess I'm wondering: what are the actual virtues of github (other
>    than that some people are already familiar with it)
>
> January 2020, GitHub reports having over 52 million users and more than
> 28 million public repositories.  Since we want to engage the open source
> community, it behooves to make accomodations, rather than try to say “use
> this, it’s better.” Fortunately, the accommodation is something the IETF
> has already approved, and left use of to individual working groups.
>

That is irrelevant. I use Git all the time for the purpose for which it is
designed - managing source code. I do not use it as a process driven
collaboration tool because it is not at all well designed for that except
within the very narrow focus of managing and tracking code.

And to go back to an earlier point, I think the fact that most working
groups only have a small core of active members is actually something we
need to think about. Whether this is a good thing or a bad thing, it is a
fact that goes completely against what the IETF claims to stand for.

IF we are ok with specifications being written by small groups with little
outside input then IETF is wasting a heck of a lot of time and effort
trying to enable cross-area review. I have absolutely no problem with the
small group model, it is the one that we adopted at W3C and one that I did
a lot of my early work in. If that is the outcome people really want, then
we should stop having three plenary meetings a year with 2 hour sessions
for 60 WGs and do the bulk of the work in all-day meetings of a single WG.

QUIC is a really bad example for people to keep bringing up because it is
completely atypical of standards work. And again, my criticism of using git
comes from spending a lot of time asking the question of how we can do
better.

>
>    - But mostly, to me, github looks like a huge impediment
>
> community agreed with you – and they don’t – the percentage would still be
> a round-off error and approximates to zero.
>

My experience of the OpenPGP BIS WG was that the attempt to use github were
one of the things that led to its failure.

Sure, I know that email isn't great either and as for Slack...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2021 12:31:55 -0500

Maybe I am missing something.  You refer to transparency of changes. 
For any document I care about, I look at the diffs between versions as 
well as at the resulting whole document.

If authors want to use git for storing documents and tracking what they 
do, that is likely beneficial to the working group.  But that has little 
or nothing to do with discussing issues on the WG email list.

Yours,
Joel

On 1/7/2021 12:03 PM, Michael Thomas wrote:
>> The discussion moved into "I want to use my tools and not yours". 
>> There is no middle ground. You want to have everyone use email so you 
>> can scan through discussions more easily. Others, who have been 
>> working on implementations are familiar with Git, and they seem to 
>> feel that they are most efficient using those tools.
>>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Jan 2021 09:32:45 -0800

On 1/7/21 9:27 AM, Kyle Rose wrote:
> On Thu, Jan 7, 2021 at 12:03 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> general, very minor changes employ a form of acclimation: unless 
> someone objects, they are assumed to have rough consensus if the 
> editors apply them. If every single change regardless of size needed a 
> consensus call, no document would ever get finished. In reality, only 
> major proposed changes get this kind of formal treatment.
>
If anybody can send a pull request of whatever magnitude and it is 
pulled by the editors, that's a process problem. That's allowing a 
backdoor to the process of achieving consensus. Yes it happens now 
regardless of git, but that doesn't make it a good thing.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 17:35:55 +0000

*   My experience of the OpenPGP BIS WG was that the attempt to use github were one of the things that led to its failure.

That WG used GitLab, not GitHub.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Jan 2021 09:36:49 -0800

On 1/7/21 9:31 AM, Joel M. Halpern wrote:
> If authors want to use git for storing documents and tracking what 
> they do, that is likely beneficial to the working group.  But that has 
> little or nothing to do with discussing issues on the WG email list.
>
Diff gets you the "what" (poorly for I-D's, imo), but it doesn't give 
you the "why" which is often more important. Capturing that history 
would be very beneficial just like with source code.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 17:44:53 +0000

>    I would like to find a middle ground.

Okay, here is a proposal for finding a middle ground.

Look at some of the standard/common "weekly summary" mail messages and provide explain what you'd like to see changed.  I don't think "include all the comments" is finding middle ground, but Chacun son gout.  Some examples of the summary include:
	https://mailarchive.ietf.org/arch/msg/tls/-mF0gOetvh8KFElPYAHZ-ih4zYY/
	https://mailarchive.ietf.org/arch/msg/quic/e0qBS7XPvEvLr0bx4dlocAhP8sg/

I suggest you also look at the email archives for surrounding context.

---

From: Kyle Rose <[email-masked]>
Date: Thu, 7 Jan 2021 12:52:54 -0500

On Thu, Jan 7, 2021 at 12:32 PM Michael Thomas <[email-masked]> wrote:

> If anybody can send a pull request of whatever magnitude and it is pulled
> by the editors, that's a process problem. That's allowing a backdoor to the
> process of achieving consensus. Yes it happens now regardless of git, but
> that doesn't make it a good thing.

But that is also not how it works. First of all, I assume authors are
acting in good faith: if there is a major change proposed, they're not
going to apply it without understanding how the WG feels about it. But even
if they're not acting in good faith, a bad change will eventually be
discovered by someone doing a diff or a review. While the "rough" in "rough
consensus" refers to the inability to get unanimity on anything, it seems
like it also permits a bit of leeway in terms of determining consensus for
purposes of efficiency and making progress: based on prior discussions in a
WG and the deep knowledge authors have about both the material and the
views of others in the WG, some changes are obviously going to be
non-controversial, so authors often use their judgment to apply them
without actually asking on the list. Bad faith actors and misjudgments will
still be discovered.

Note that this is a separate issue from fragmentation/participants not
knowing about all the work going on that they might have opinions about. I
don't see that as a GitHub workflow or minor change issue so much as an
issue of there being so much work that no one can keep track of it all.

Kyle

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2021 13:17:28 -0500

Sorry, a once a week summary, no matter how good, does not let someone 
engage in the conversation.  Also, responding to emails from such a 
summary in a fashion that is understandable is quite difficult.

So no, I do not consider that a useful middle ground.

Yours,
Joel

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 18:21:38 +0000

Your also comment brings to mind a question I asked earlier:  did you ever subscribe to the RISKS or other digests?  Ever reply to a posting there?

Have you followed any GitHub repo's, and seen the email that comes when someone comments on an issue or pull request?  Did you know you can click on "watch"?  https://docs.github.com/en/free-pro-team@latest/github/managing-subscriptions-and-notifications-on-github/configuring-notifications

>    So no, I do not consider that a useful middle ground.

Your turn to make a proposal.

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 7 Jan 2021 13:30:00 -0500

I read Comp Risks.  While I have not responded to postings there, if I 
did, due to the way it works I would have to extract a reference to the 
piece I wanted to reply to, and respond to it.

But comp.risks demonstrates a significant part of the problem.  When I 
read replies there, I frequently have to scratch my head to figure out 
what they are commenting on.  And conversations there are almost always 
very short.  I grant that following deep conversations on email is 
tricky.  I would like better support.  But following them on a digest is 
essentially impossible.

And as I said, getting a digest once a week effectively excludes one 
from most of the conversation.

Yours,
Joel

---

From: [email-masked]
Date: Thu, 07 Jan 2021 09:27:50 -0800 (PST)

> The discussion moved into "I want to use my tools and not yours". 

Not really. You began this particular subthread when you attempted to
defend the "let all the flowers bloom" approach by saying:

  for cross area reviews all you need are IETF drafts. I doubt that reviewers
  are  interested in digging through the Github issues, PRs, and mailing list
  discussions.

Speaking as 30 year IETF participant, including four years as an apps AD and
many stints as a WG chair, this is not now and has never been my experience. I
could not even begin count the number of times I've had to review mailing list
discussions as part of reviewing a draft.

This was especially true when performing cross-area reviews as an AD, where
let's just say that asking questions about contentious issues without being
intimately familiar with the background was not a recipe for success.

And in the past month or so, while participating in DMARC and EMAILCORE, I've
been compelled to dig into the archives of various lists at least a dozen
times, maybe more.

So maybe the drafts are enough in your world. But they most definitely are
not in mine.

Of course this becomes a serious problem if the material I need to review ends
up scattered across multiple tools.

This isn't a matter of "my tool is better than yours". As it happens I use git
on a daily basis and modulo some issues with terminology I quite like it.

That said, to the extent I have problems with git, it's because I also
regularly use Mercurial - which as it happens I dislike - and constantly
transitioning between the two can be ... jarring. 

And this leads me to the closely related issue: Context switching. Even if a
single tool is used for developing a given draft, having to constantly switch
between a bunch of different tools for different drats or WGs or whatever is
also a major PITA.

>  There is no middle ground. You want to have everyone use email so you can
>  scan through discussions more easily. Others, who have been working on
>  implementations are familiar with Git, and they seem to feel that they are
>  most efficient using those tools.

Nope. I don't especially care what tools are used. What I want is consistency,
because anything else brings with it very substantial costs, costs you are
dismissing in a cavalier way that borders on offensive.

And like it or not, we have 35+ years of discussions of drafts captured in
mailing list archives that are not going anywhere. This is a real cost that
cannot be poo-poo'ed away with handwaving arguments about use of obsolete
technology.

The benefits of any new approach have to be weighed against these costs.

> Regarding "those who actually do the bulk of the work". There are lots of
> steps to get to widespread deployment of technology. Writing the spec is only a
> small part of the job. Producing implementations of the specs, and deploying
> them is a big part of it. Sometimes you can observe that people write
> specifications and then they run away because they believe the work is done. It
> is often more exciting to work on the latest thingy rather than doing the other
> 20% of the work that take 80% of the time.

> Those folks in the community who do also the last 20% should get credit and
> if we can make their life easier I believe we will get not only more done but
> we will also be more successful as an organization.

Hmm. You started by saying that in order to review a draft all you need is the
draft itself. But apparently to *implement* a draft it's useful if not
essential for the discusions of that draft to be stored in an "implementor
friendly" way.

I think you just contradicted yourself.

In any case, and now speaking as someone who has often gone back to my hotel
room after a session and implemented the latest changes in the draft, I find
early implementation and review both require access to the discussion of
issues. And not to put too fine a point on it, I'd be far less inclined to
implement an in-progess draft if the issue discussions are somwwhere other than
on the mailing list. Not because the list is the technology I prefer, but
because it's technology I have to use for other drafts.

Actually make that, "Pigs will fly first".

				Ned

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2021 13:33:32 -0500

With regard to "your turn to make a proposal"...
I started with a suggestion.  I would not call it a proposal because to 
act on it would require more knowledge of what git can and can't do than 
I possess.  I presume from the various people ignoring that suggestion, 
that there are serious difficulties in producing understandable emails 
from git.

Maybe some other folks have ideas worth exploring?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Jan 2021 13:35:05 -0500

On whether I have watched git, I have seen the emails that git produces. 
  As other people have commented, they are extremely hard to use for a 
discussion.   That is why I keep talking about useful and udnerstandable 
emails.

Yours,
Joel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Jan 2021 10:52:39 -0800

> discussions as part of reviewing a draft.

I hope that you would agree that that exercise is much akin to looking 
for needles in haystacks, right? That's why I'm saying that an editing 
audit trail to establish the "why" would be useful, and could hopefully 
narrow the search space substantially, if not answer those questions 
outright.

> been compelled to dig into the archives of various lists at least a dozen

What is your take of the current regimen in DMARC of requiring issues to 
be opened on the issue tracker and only discussed when the chairs get 
around to it? I've never seen that before, but I've been MIA for quite a 
while too. For one, it requires active participation by the chairs which 
has been... its own problem. But it also causes a weird flow given the 
FIFO nature of an issues tracker. That was my first experience with the 
IETF issues tracker, and frankly it left me with the feeling that it was 
an easy way for chairs to just dismiss an issue in hopes the person with 
the issue forgets about it.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 18:54:00 +0000

>    On whether I have watched git, I have seen the emails that git produces.

Did you subscribe to a repo and actually get a mail stream yourself?  Or just seen a couple of messages?

That is not my experience, and I participate in several high-volume GitHub projects.

Yes, you keep talking about "useful and understandable"  Perhaps you should add "to me" since I find the GitHub emails useful and understandable.

---

From: Tim Bray <[email-masked]>
Date: Thu, 7 Jan 2021 10:56:42 -0800

This is not an abstract debate. I'm co-chairing the recently-chartered
jsonpath WG and the co-editors said "we can use GitHub, right?"

We have to face the fact that this will inevitably create two separate
channels where design discussions will occur; GitHub issues and the mailing
list.  On the other hand, I appreciate the commitment of co-editors and am
very reluctant to tell them they shouldn't use the tools that make them
productive.

[BTW, as we discuss this let's keep a clear discussion between the
admittedly-arcane git semantics and the fairly-reasonable issue/diff
management offered by GitHub.]

People who find all this worrying should start girding up their loins for
the inevitable wave of people wanting to take it all to Slack… [/me ducks]

On Thu, Jan 7, 2021 at 10:35 AM Joel M. Halpern <[email-masked]> wrote:

> > Your also comment brings to mind a question I asked earlier:  did you
> ever subscribe to the RISKS or other digests?  Ever reply to a posting
> there?
> >
> > Have you followed any GitHub repo's, and seen the email that comes when
> someone comments on an issue or pull request?  Did you know you can click
> on "watch"?
> https://docs.github.com/en/free-pro-team@latest/github/managing-subscriptions-and-notifications-on-github/configuring-notifications
> >

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Jan 2021 17:53:22 -0500

Phillip Hallam-Baker <[email-masked]> wrote:
    PHB> My experience of the OpenPGP BIS WG was that the attempt to use github were
    PHB> one of the things that led to its failure.

Salz, Rich <rsalz=[email-masked]> wrote:
    RS> That WG used GitLab, not GitHub.

PHB,
I don't know what happened, or whether it was GitLab or GitHub.
I do know that it was at least five years ago, right?
I would appreciate some summary of what went wrong?
Was it really the tool?  Was it people using the tool wrong?
Were they fighting the tool?
Were they disagreeing (maybe even implicitely) on how to use the tool?

I'm asking this to understand what a better tool would actually do.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 23:08:53 +0000

It wasn't the tool, and it wasn't GitLab's tooling around git.

There wasn't enough interest from the WG, the doc editor didn't get involved much, and the WG chairs were new.

I was a WG member from the beginning and attended all F2F meeting.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jan 2021 12:28:34 +0000

On 1/7/21 9:27 AM, [email-masked] wrote:
> Speaking as 30 year IETF participant, including four years as an apps
> AD and many stints as a WG chair, this is not now and has never been
> my experience. I could not even begin count the number of times I've
> had to review mailing list discussions as part of reviewing a draft.

If the document you are supposed to be reviewing does not give enough context so that you have to review the mailing list discussions then there is clearly something wrong with the document.
That should have been your review comment.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jan 2021 13:54:00 +0100

> That should have been your review comment.

As a reviewer, I try not to relitigate discussions that the WG already had.
The outcome will be documented in the spec, but not the reason why it differs from my personal preference.

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Jan 2021 13:02:09 +0000

Hiya,

On 08/01/2021 12:28, Hannes Tschofenig wrote:
> If the document you are supposed to be reviewing does not give enough
> context so that you have to review the mailing list discussions then
> there is clearly something wrong with the document. That should have
> been your review comment.
I thought Ned was discussing drafts that were works-in-
progress rather than what a WG considered the finished
product. For the former, I agree with Ned that reviewing
list discussion is sometimes needed. And while yes, in
the ideal case, after WGLC a draft would stand alone in
theory, in practice I'm sure there are valid cases where
is does not, e.g. if the WG decided to punt on feature X.

More generally, on the topic of better glue between github
and mailing lists, I wonder has anyone tried to use the
labels that can be attached to issues on github, so that
posts to issues marked "for the list" (or whatever) would
be sent to the list with the ability to get email replies
back into the github issue? Some mechanism like that could
give WG chairs a tool that could allow them to "join" list
and github issue discussions maybe.

Cheers,
S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jan 2021 13:04:23 +0000

Hi Carsten,

I guess we have different expectations of how much time a reviewer should spend on their document review.

With relevance to this discussion the question is: did the use of tools like Github make your review activities more or less difficult to do this type of "background check"?

Ciao
Hannes

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Sent: Friday, January 8, 2021 1:54 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Thomas <[email-masked]>; [email-masked]
Subject: Re: Old directions in social media.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 8 Jan 2021 14:04:52 +0100

Hi Hannes, Mike, Ned, and others,

I do think there is a transparency risk that is related to DISCUSSes and appeals that has to be considered.  However, RFC 8875 does discuss how to address that, though perhaps with a focus on DISCUSSes and appeals, in Section 3.2.

I have a bit of sympathy with Joel on not wanting to bifurcate conversations.  It’s not a matter of gray hair to me, but simply a matter of wanting to participate in formative discussions.  If they’re not happening on email, then one needs to know where they are happening, and be able to get in the game.  I don’t think there’s a perfect solve for that, but it seems to me that the concern is somewhat obviated if WGs virtually meet often.  There is, of course, a convenience tradeoff there...

Eliot

> On 8 Jan 2021, at 13:28, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jan 2021 14:08:39 +0100

On 2021-01-08, at 14:04, Hannes Tschofenig <[email-masked]> wrote:
> With relevance to this discussion the question is: did the use of tools like Github make your review activities more or less difficult to do this type of "background check”?

Normally, I’d check out the repo and look at the most recent commits for the general area that I have questions about — that might lead me to pull requests and the issues they close.  A keyword search in the issues might also yield (as I would do in the mailing list).

Independent of github vs. mail, that obviously can be done for one or two issues, not for 30.
(If there are 30 issues where I disagree with the document, maybe we have greater problems.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Jan 2021 14:10:12 +0100

On 2021-01-08, at 14:04, Eliot Lear <lear=[email-masked]> wrote:
> 
> concern is somewhat obviated if WGs virtually meet often

Much, MUCH worse.

For a reviewer, this means I now have to slog through recordings and inscrutable minutes.

I’d rather have github issues to look at.

Grüße, Carsten

---

From: Michael Thomas <[email-masked]>
Date: Fri, 8 Jan 2021 07:20:27 -0800

> is does not, e.g. if the WG decided to punt on feature X.
My inner Luddite says that if I need to understand the context from the 
discussions, then the document is not baked enough.

Mike

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jan 2021 09:55:42 -0600

Folks, I see heated discussions on this thread, but I missed its beginnings.
I would appreciate if someone shortly describes what is being discussed and
what has been learned so far?

Behcet

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jan 2021 08:03:28 -0800

Phillip Hallam-Baker <[email-masked]> writes:

> That is irrelevant. I use Git all the time for the purpose for which
> it is designed - managing source code. I do not use it as a process
> driven collaboration tool because it is not at all well designed for
> that except within the very narrow focus of managing and tracking
> code.

More specifically, github is designed around tracking and managing
things (not just code) that have very little subjectivity in what is
being tracked.  Issue 5 is created because code is failing a test or
feature and needs to be fixed.  Though there may be fights over the
right way to implement a feature, or whether spaces and tabs are used,
they're short lived and in the end most decisions in things that end up
in git are objectively measurable as to whether an issue should be
closed.

That's not true for IETF discussions where there are huge amounts of
back and forths, and restatements, and a lot of objectivity in the
discussions.  That's where issue trackers will break down the most.

-- 
Wes Hardaker
USC/ISI

---

From: Kyle Rose <[email-masked]>
Date: Fri, 8 Jan 2021 11:07:12 -0500

Tl;dr: Old man yells at cloud. Other old men yell back.

The thread starts here:

https://mailarchive.ietf.org/arch/msg/ietf/K0o3LACAN_xysoD8zlaqQgQN5rE/

On Fri, Jan 8, 2021 at 10:56 AM Behcet Sarikaya <[email-masked]>
wrote:

> I would appreciate if someone shortly describes what is being discussed
> and what has been learned so far?
>
> Behcet
>

---

From: Kyle Rose <[email-masked]>
Date: Fri, 8 Jan 2021 12:31:10 -0500

Staying on the same thread (so those who've muted can retain their sanity),
but resetting a bit...

Instead of welcoming new ideas and new ways of working into the milieu, and
expressing appreciation that others want to put in effort to contribute to
this shared venture, you and others are suggesting we micromanage the terms
of engagement. First of all, perhaps you don't realize that we old folks
are not going to be calling the shots forever and shouldn't be able to cast
our preferences in high-pressure concrete. Frankly, either we meet new
participants halfway, or the IETF becomes irrelevant as more welcoming
forums take over new work. Based on what I'm seeing, maybe that would be
for the best.

But more importantly, I think this whole conversation is focused on the
wrong problem. Rough consensus is a tool, and "rough" is an important part
of its description. If you endeavor to design a process to look like a wire
protocol, you will fail because human interactions don't work that way. In
the legal arena, this is expressed as "hard cases make bad law." Throwing
up process impediments in a vain effort to make sure bad documents don't
ever get published will also result in good documents not being published,
and participants becoming discouraged and going elsewhere.

A successful standards process that admits open participation will
necessarily be agile: iterative and based on frequent stakeholder
engagement and fast feedback. *That* is where effort improving the IETF
working model needs to be focused. Instead of trying to rule-make our way
to ensuring you and everyone else is handed an opportunity to get the last
word in on every change, document authors and WG chairs need to work to
identify a representative set of stakeholders for each standards effort and
make sure those stakeholders are engaged continuously in the iterative
process of requirements gathering, design, build, test, and feedback.
That's hard work because it requires a level of sustained attention and
effort that goes way beyond monitoring a mailing list.

I assert, simply based on my observations over the past several years, that
many participants are unwilling to put in this kind of sustained effort,
and so they advocate for gates, control points, and convenience *for them*
so they don't need to pay close attention while still not missing anything.
This is absurd and frankly ass-backwards. If you want a say, you should be
prepared to pay close attention, and that means going to where the work is
rather than expecting it to come to you.

Kyle

---

From: tom petch <[email-masked]>
Date: Fri, 8 Jan 2021 17:33:23 +0000

> Maybe some other folks have ideas worth exploring?

That the tool has little to do with it.  If someone is incompetent with 
a mattock, then likely they will be incompetent with a spade or a 
shovel.  If they lack the methodology, the discipline, the approach, 
then the choice of tool is likely to be of little import, especially, as 
has been pointed out here, the tools were designed for other arenas of 
work, such as code.

I see 2020 as a time when less got done, when the work of the IETF 
slowed down such that I had to make detailed notes so that when the 
issues came up again - much later - I could see what I said and why and 
carry on the discussion - I even write things down on paper!

Examples:
- a WG LC that was called six months ago, has generated some discussion 
but has not been brought to a conclusion
- a RYO version of the RFC8174 boilerplate that was put right after a 
comment but two versions of the I-D later, had reverted to the RYO 
version; the WG has done this with other textual changes, too
- a WG that produces new versions of its I-Ds just before the IETF 
meeting cutoff, does not respond on the mailing list to comments and 
then produces new versions of its I-Ds just before the next meeting 
cutoff (anyone recall a jest about monks discussing porridge?)
- a WG which comes back, a week or two after a comment, with the 
response that the design team (ie a group of authors and their 
colleagues, nothing formal) have discussed this and have decided xxx - 
with, apart from the author posting to the list, no indication who else 
is involved in this decision
- an I-D in the RFC Editor Queue for 835 days, held on a Normative 
Reference for which the I-D has made no progress for months and seems 
likely to stay that way; roll on 2022
etc., etc.

I would characterise these as there are managerial solutions to 
technical problems but no technical solutions to managerial problems ie 
a new tool or toolset will not improve things.

Tom Petch

>> Have you followed any GitHub repo's, and seen the email that comes
>> when someone comments on an issue or pull request?  Did you know you
>> can click on "watch"?
> .

---

From: [email-masked]
Date: Fri, 08 Jan 2021 09:18:49 -0800 (PST)

> If the document you are supposed to be reviewing does not give enough context
> so that you have to review the mailing list discussions then there is clearly
> something wrong with the document.

> That should have been your review comment.

And in those cases where a choice made in the document doesn't quite jibe with
your memory of what transpired in a meeting... which may be wrong... but you
weren't on the list so don't know what went down later.. what then?

Or when some text in a document published long ago and now being revised
doesn't line up with operational practice you've seen, and you need to know the
WG's reasoning for the choice, or for that matter whether they were even aware
at the time that the alternate practice existed?

Or any of a thousand other variations and permutations that can occur along the
often highly nonlinear paths our documents often take? 

Or are you seriously suggesting that all of the discussions leading to every
design choice, discussions which for the most trivial of matters can run into
dozens of messages and thousands of words, should be faithfully captured in the
document itself?

And with this, I'm done. You are clearly operating in some other reality than
the one I occupy, and I have no more time to waste trying to understand it.

				Ned

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 8 Jan 2021 17:47:06 +0000

> I would appreciate if someone shortly describes what is being discussed 

What's being discussed is how the IETF should use easily accessible, 
general purpose, commonly-available tools which are specifically 
designed to precisely handle the sorts of things that the IETF and its 
participants need to do, and in the way that suits everyone best at an 
individual basis because that's the tool they've always used, except for 
new tools which we need to design and build to match all these 
requirements.  It's important that this should happen at zero cost to 
anyone, but particularly IETF participants.  And the IETF.

Additionally, everyone wants to make it clear that everyone else's tools 
are also completely welcome unless they happen not to suit everyone's 
purposes perfectly, in which case, they are clearly a hindrance and 
shouldn't be used.  Obviously, the more tools in this category, the 
better.  Particularly git, or not (and Github, or not).

> and what has been learned so far?

That the quantity of hot air emitted in the course of this and other 
discussions on ietf@ could power the earth for generations.

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 Jan 2021 12:48:18 -0500

Kyle, I would like to find a technique that works for folks like me, and 
works for new folks who are used to different paradigms.    But the 
suggestions that have been offered (like weekly digests) simply miss the 
point.  Maybe part of the problem is different assumptions about how 
people engage at the IETF.  I have at least a dozen WGs that I am 
actively involved with, and probably twice as many that I try to watch 
with enough attention and knowledge that a I can appropriately 
participate when I need to.  While I have a good memory, I rely on 
context in the emails to help me manage that much variation. (And no, I 
do not expect all of the context.)

No solution is perfect, and I am not asking that the next modification 
to how we work be perfect for me or anyone else.  But that does not mean 
I should agree to things that are extremely unproductive for me or others.

Yours,
Joel

PS: While change and evolution is necessary, it seems to me that those 
asking for changes need to justify and accommodate.  The assumption that 
we must use the current great thing does not seem appropriate.

On 1/8/2021 12:31 PM, Kyle Rose wrote:
> Staying on the same thread (so those who've muted can retain their 
> sanity), but resetting a bit...
> 
> Instead of welcoming new ideas and new ways of working into the milieu, 
> and expressing appreciation that others want to put in effort to 
> contribute to this shared venture, you and others are suggesting we 
> micromanage the terms of engagement. First of all, perhaps you don't 
> realize that we old folks are not going to be calling the shots forever 
> and shouldn't be able to cast our preferences in high-pressure concrete. 
> Frankly, either we meet new participants halfway, or the IETF becomes 
> irrelevant as more welcoming forums take over new work. Based on what 
> I'm seeing, maybe that would be for the best.
> 
> wrong problem. Rough consensus is a tool, and "rough" is an important 
> part of its description. If you endeavor to design a process to look 
> like a wire protocol, you will fail because human interactions don't 
> work that way. In the legal arena, this is expressed as "hard cases make 
> bad law." Throwing up process impediments in a vain effort to make sure 
> bad documents don't ever get published will also result in good 
> documents not being published, and participants becoming discouraged and 
> going elsewhere.
> 
> working model needs to be focused. Instead of trying to rule-make our 
> way to ensuring you and everyone else is handed an opportunity to get 
> the last word in on every change, document authors and WG chairs need to 
> work to identify a representative set of stakeholders for each standards 
> effort and make sure those stakeholders are engaged continuously in the 
> iterative process of requirements gathering, design, build, test, and 
> feedback. That's hard work because it requires a level of sustained 
> attention and effort that goes way beyond monitoring a mailing list.
> 
> I assert, simply based on my observations over the past several years, 
> that many participants are unwilling to put in this kind of sustained 
> effort, and so they advocate for gates, control points, and convenience 
> *for them* so they don't need to pay close attention while still not 
> missing anything. This is absurd and frankly ass-backwards. If you want 
> a say, you should be prepared to pay close attention, and that means 
> going to where the work is rather than expecting it to come to you.
> 
> Kyle
> 
> On Fri, Jan 8, 2021 at 11:03 AM Wes Hardaker <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Phillip Hallam-Baker <[email-masked]
>     <mailto:[email-masked]>> writes:
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jan 2021 13:22:08 -0500

On 1/8/21 12:31 PM, Kyle Rose wrote:

> Instead of welcoming new ideas and new ways of working into the 
> milieu, and expressing appreciation that others want to put in effort 
> to contribute to this shared venture, you and others are suggesting we 
> micromanage the terms of engagement.

You say "new" as if it were inherently a Good Thing.  It's not. "New" is 
not by itself a good reason to welcome something.   That kind of 
argument is basically an appeal to prejudice, and an argument based on 
"new" vs. "old" is at best a distraction.    I'd like to see more 
insight as to why a tool or a way of working is better or worse than 
another.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Jan 2021 13:32:37 -0500

On 1/8/21 12:33 PM, tom petch wrote:

>
> That the tool has little to do with it.  If someone is incompetent 
> with a mattock, then likely they will be incompetent with a spade or a 
> then the choice of tool is likely to be of little import, especially, 
> as has been pointed out here, the tools were designed for other arenas 
> of work, such as code. 

Agree with that much.  But in the hands of a competent individual, the 
choice of tools matters a great deal.   And one kind of competence is 
being able to choose more effective tools.

Keith

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 8 Jan 2021 10:37:12 -0800

On 1/8/21 10:22 AM, Keith Moore wrote:
>> Staying on the same thread (so those who've muted can retain their sanity), but resetting a bit...
>>
>> Instead of welcoming new ideas and new ways of working into the milieu, and expressing appreciation that others want to put in effort to contribute to this shared venture, you and others are suggesting we micromanage the terms of engagement.
> 
> You say "new" as if it were inherently a Good Thing.  It's not. "New" is not by itself a good reason to welcome something.   That kind of argument is basically an appeal to prejudice, 

Technically, appeal to novelty (/argumentum ad novitatem/).

> and an argument based on "new" vs. "old" is at best a distraction.    I'd like to see more insight as to why a tool or a way of working is better or worse than another.
> 
> Keith
> 
> 
> 

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Jan 2021 22:20:31 -0500

Salz, Rich <[email-masked]> wrote:
    > There wasn't enough interest from the WG, the doc editor didn't get
    > involved much, and the WG chairs were new.

    > I was a WG member from the beginning and attended all F2F meeting.

I see, thank you.

If you haven't read http://xprogramming.com/articles/jatbaseball/
   We Tried Baseball and It Didn't Work

then please do, as it sure sounds like this happened, and that the criticism
of github/gitlab parallels this.

---

On a number of bigger open source projects that I am involved in, I find github
excessively noisy and 80% of tickets just gum up the machine.  Integration
with a stackexchange-like thing would be nice to have.  (That would be
inappropriate for IETF work)

In some other projects, issues are opened and then closed faster than anyone can
actually keep up.

But, in many of the IETF *DESIGN TEAM* efforts, where the design team has regular
meetings, I find github rather effective.  Certainly far more useful than we
we tried to use trac.  (And, back in 2007, I was a major fan of trac)

---

From: John C Klensin <[email-masked]>
Date: Sat, 09 Jan 2021 00:39:06 -0500

--On Friday, January 8, 2021 14:04 +0100 Eliot Lear
<lear=[email-masked]> wrote:

>...
> I have a bit of sympathy with Joel on not wanting to bifurcate
> conversations.  It's not a matter of gray hair to me, but
> simply a matter of wanting to participate in formative
> discussions.  If they're not happening on email, then one
> needs to know where they are happening, and be able to get in
> the game.  I don't think there's a perfect solve for that,
> but it seems to me that the concern is somewhat obviated if
> WGs virtually meet often.  There is, of course, a convenience
> tradeoff there...
>...

Eliot, it isn't just convenience.  More virtual meetings means
more timezone problems and some people being excluded from the
discussions even if only on a rotating basis.  And, however good
the minutes or ability to play back recorded video, it is not as
good as being able to make comments or insert an issue or
perspective while the meeting is going on... and the topic might
get lost by the next meeting.    So, whether by email, github,
or something else (a separate topic and taking up most of the
thread), mechanisms that allow input to be provided and
discussed asynchronously [1] tend to work out better for
high-quality participation of consideration of issues than many
/ frequent interim meetings.

    john

[1] Personally, although it might be a consequence of the color
and diminishing quantity of my hair, I continue to find github
much harder to follow it I am not watching an issue continuously
than email although email can get difficult too when the
discussion occurs as this thread has.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 9 Jan 2021 11:10:59 +0100

Hi John,

> On 9 Jan 2021, at 06:39, John C Klensin <[email-masked]> wrote:
>> ..
> 
> discussions even if only on a rotating basis.

This is what I was alluding to.  Yes, there’s a cost.

> And, however good

I am not suggesting an “either/or”, but rather an amelioration of the partitioning associated with people picking their preferred mode of communication outside of meetings, so that any perceived formative discussions don’t go on too long without being picked up in an interactive discussion.  As you point out, there’s a price for that amelioration, which impacts people differently.

Absent such an amelioration, our alternatives seem to be to live with that partitioning or impose a common platform on everyone, making one group or another quite unhappy.  In an organization driven by rough consensus, that seems to be a challenge.  Do you see it differently?

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 9 Jan 2021 17:10:19 -0500

I take offense at this description of my work and demand an immediate
apology.

What I said was that I am already building a tool whose primary target
audience is outside IETF scope (confidential, end to end encrypted
interactions) but that the tool might be of interest to IETF as it builds
on existing approaches with improvements.

Of course I didn't expect the folk who can't understand what is wrong with
nroff to understand the limitations of github. In fact I notice that a lot
of engineers are unable to produce quality work precisely because they have
no aesthetic judgement. Gates did, Jobs did and now Musk does. The ability
to look at existing systems and understand why they are defective is the
first step towards replacing them with something better

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 10 Jan 2021 03:53:28 +0000

*   I take offense at this description of my work and demand an immediate apology.
…

  *   Of course I didn't expect the folk who can't understand what is wrong with nroff to understand the limitations of github.

So do you want an apology from someone’s snarky/meme-invoking summary of a big thread on ietf@?  Or is it not necessary since you insulted in return?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Jan 2021 12:05:59 -0500

There is a big difference between making only one comment that is
deliberately insulting and making a comment that some people are going to
take offense at but is an accurate description of the situation.

My comment was pointing out that the github discussion had turned into an
editor war discussion. As I keep pointing out, the starting point here is
git is a source code manager with some ad hoc process capabilities bolted
on and I intend to build a process collaboration capability.

Selling the technology back to Microsoft/Github might well end up being one
of the exit strategies. It might have escaped notice but you are not
limited to using git on github.

On Sat, Jan 9, 2021 at 10:53 PM Salz, Rich <[email-masked]> wrote:

>
>
>    - I take offense at this description of my work and demand an
>    immediate apology.
>
> …
>
>    - Of course I didn't expect the folk who can't understand what is
>    wrong with nroff to understand the limitations of github.
>
>
>
> So do you want an apology from someone’s snarky/meme-invoking summary of a
> big thread on ietf@?  Or is it not necessary since you insulted in return?
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Jan 2021 12:15:35 -0500

On Fri, Jan 8, 2021 at 1:22 PM Keith Moore <[email-masked]>
wrote:

> and expressing appreciation that others want to put in effort to contribute
> to this shared venture, you and others are suggesting we micromanage the
> terms of engagement.
>
> You say "new" as if it were inherently a Good Thing.  It's not.
>
New is inherently a Good Thing.

This is a technology organization and I was proposing to develop a new
technology and asking for input. At this point I am designing a new
capability and asking people what features they would want if they were to
use it.

I am not proposing people use the system because it doesn't exist yet. I am
asking questions now because it will be much harder to change things once
something is built.

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 Jan 2021 12:20:21 -0500

On 1/10/21 12:15 PM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Jan 8, 2021 at 1:22 PM Keith Moore <[email-masked] 
>>     milieu, and expressing appreciation that others want to put in
>>     effort to contribute to this shared venture, you and others are
>>     suggesting we micromanage the terms of engagement.
>

Disagree.  New tools and technology are not always better than old, even 
if the cost of retraining is ignored.   Generally the marketplace sorts 
those things out, which might explain some of the bias, but this does 
not happen in every sphere.

This isn't a statement about what you're developing of course, since I 
have no visibility into it.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 10 Jan 2021 13:19:38 -0500

OK, so people have pointed out that I may have misidentified the targets
Kyle was addressing.

But isn't the fact that we have a mega thread and nobody is actually
responding to the original question I raised kind of the point? Email isn't
great and neither is git. The question I am asking is 'what would be great'.

The Mesh now passes all its unit tests and I can start planning an alpha
release. Up till now I have been deliberately avoiding presenting it to
users as I didn't want to find out that the 'encrypted' password catalog
was actually en-clair or the like. So I will be breaking it out of the test
framework and making it a tool people can start using.

The solarwinds breach was caused because someone put a password in a
script. One of the things the tool does is provide a way to write a script
that requires a password without embedding the password in the script.

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 Jan 2021 18:19:47 -0500

On 1/10/21 1:19 PM, Phillip Hallam-Baker wrote:

> responding to the original question I raised kind of the point?

Only if we actually care about the answer to the original question :)

(actually having just reread that message - what was the question you 
were raising?   I don't think it's clear from the message.)

I have actually prototyped an email user interface that tried to 
encourage people scan through email messages and indicate agree/disagree 
and add brief per-paragraph annotations, with agrees/disagree counts and 
annotations displayed when reading the subject messages, as an 
alternative to making arbitrary replies. (Replies were still possible, 
of course.)    So I've had at least somewhat similar ideas to what you 
propose but I was trying to make it compatible with email so as to not 
lose the many advantages that email has.

Keith

---

From: Lloyd W <[email-masked]>
Date: Tue, 12 Jan 2021 20:29:38 +1100

Automatic translation would be an added twist to
https://www.ietf.org/archive/id/draft-wood-discussion-beyond-english-00.txt

"Of course discussions do occur in languages other than English, but I've rarely seen mailing list discussions in languages other than English.   

"(I do think it's unfortunate that non-English speakers are at somewhat of a disadvantage in IETF.   But one person who was not a native English speaker said to me "Using English is a lot like using a standard protocol".   Who knows, maybe automatic translation is now good enough that we could each subscribe to mailing lists in our preferred language.  It would be an interesting experiment.)"

Lloyd Wood
[email-masked]

> On 6 Jan 2021, at 10:32, Keith Moore <[email-masked]> wrote:
> 
> Of course discussions do occur in languages other than English, but I've rarely seen mailing list discussions in languages other than English.   
> 
> (I do think it's unfortunate that non-English speakers are at somewhat of a disadvantage in IETF.   But one person who was not a native English speaker said to me "Using English is a lot like using a standard protocol".   Who knows, maybe automatic translation is now good enough that we could each subscribe to mailing lists in our preferred language.  It would be an interesting experiment.)