Subject: [tao-discuss] Review Request for Possible Revision of the Tao of the IETF

From: Niels ten Oever <[email-masked]>
Date: Thu, 7 Apr 2022 16:46:25 +0200

Dear IESG,

As the editor of the Tao of the IETF I would like to, as per RFC 6722, request your review for a possible new revision of the Tao.

You can find the Possible New Revision of the Tao here: http://www.ietf.org/tao-possible-revision.html and here: https://github.com/ietf/tao/blob/main/Tao.md

You can find the current version of the Tao here: https://www.ietf.org/about/participate/tao/ and here: https://github.com/ietf/tao/blob/ae31db516c1c5cade50a25640f528bb36e81bc5e/Tao.md

In this version we did a full edit of the Tao to make it shorter and more readable, updated markdown to be compliant with the IETF's website CMS (Wagtail), and updated a lot of outdated information.

We made new iterations through discussions on the Tao-discuss mailinglist and by organizing a Tao edit-a-thon with contributions from different parts of the community.

I am looking forward to your review. Of course PR's are more than welcome.

Once you approve the Possible Revision, it can be published on the IETF website.

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Affiliated Faculty - Digital Democracy Institute - Simon Fraser University
Non-Resident Fellow 2022-2023 - Center for Democracy & Technology
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Research Fellow - Centre for Internet and Human Rights - European University Viadrina

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221

---

From: Lars Eggert <[email-masked]>
Date: Thu, 7 Apr 2022 18:16:21 +0300

Hi,

> You can find the Possible New Revision of the Tao here: http://www.ietf.org/tao-possible-revision.html and here: https://github.com/ietf/tao/blob/main/Tao.md

is there a way to view a diff between the proposed and current versions?

Thanks,
Lars

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Apr 2022 16:27:24 +0000

>    is there a way to view a diff between the proposed and current versions?

I don't think that would be useful as almost every single line has changed:
	- Markup changes
	- Line-wrapping (one line/paragraph to old-school 78 char lines)
	- Massive content changes
	- Some sections moved around
If you have the git repo locally, then you can more or less do a diff but it's huge:
	; g diff dae5894fb8b5bcc848fe0c3493bd732c8bd9a033 | wc
	    2833   34623  219639
	; wc Tao.md 
	    1875   14972   95888 Tao.md

BUT MORE IMPORTANTLY, I don't think a comparison/diff review is particularly useful. I encourage people to read the document and see if it's useful to newcomers, or it's omitting things or goes into too much detail, or has factual errors.

Hope this helps.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 7 Apr 2022 20:31:58 +0300

Hi,

> BUT MORE IMPORTANTLY, I don't think a comparison/diff review is particularly useful. I encourage people to read the document and see if it's useful to newcomers, or it's omitting things or goes int…

makes sense, if there are sweeping changes.

I would ask though that going forward, we find a way for the IESG to review just the changes to the Tao again - that is how we usually evaluate "bis" documents. ADs don't have much time, and reviewing a diff is much faster than reviewing an entire document.

Thanks,
Lars

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Apr 2022 19:52:52 +0000

>   I would ask though that going forward, we find a way for the IESG to review just the changes to the Tao again - that is how we usually evaluate "bis" documents. ADs don't have much time, and revi…

FWIW, I recommend that going forward, the IESG doesn't review this document, as it doesn't officially review the rest of the website either.
Maybe it should be an EMODIR document.

Ah well, I'll have a 6722-bis to bring to DISPATCH for IETF 114.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2022 08:36:07 +1200

> FWIW, I recommend that going forward, the IESG doesn't review this document, as it doesn't officially review the rest of the website either.

And there's the bug. Not only the lack of IESG review, but also the lack of community review, of our face presented to the world.

> Maybe it should be an EMODIR document.

EMO does a great job. But that doesn't exempt their output from community review.

I urge the IETF, busy as you are, to take this review issue seriously.

    Brian

> _______________________________________________
> tao-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tao-discuss
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Apr 2022 20:46:07 +0000

>    And there's the bug. Not only the lack of IESG review, but also the lack of community review, of our face presented to the world.

The Tao is not the fact we present to the world: the homepage is.  The Tao is one page among many on that site.  I tried, and could not generate a web-search query that showed "Tao.html" in the first page of results.  Can you?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2022 08:50:55 +1200

> I urge the IETF, busy as you are, to take this review issue seriously.

I meant:

I urge the IESG, busy as you are, to take this review issue seriously.

But I wasn't wrong. I think RFC6722 was very wrong not to require IETF
review of updates to the Tao, especially for a massive update like this
one. It's quite unreasonable to put that extra load on the IESG alone.
RFC6722 being informational, it isn't a rule, so I urge the IESG to
put this out for community review. That can only make it better.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2022 08:52:38 +1200

> The Tao is not the fact we present to the world: the homepage is.  The Tao is one page among many on that site.  I tried, and could not generate a web-search query that showed "Tao.html" in the fir…

Haven't tried. However, I meant the whole web site. It would all benefit from community review.

    Brian

---

From: Lars Eggert <[email-masked]>
Date: Fri, 8 Apr 2022 11:21:39 +0300

Hi,

> put this out for community review. That can only make it better.

if people think that RFC6722 should be revised, the other thing I find problematic about it is that Section 2 prescribes a certain detailed way in which proposed changes are supposed to be published, archived, etc. This might have made sense at publication time in 2012, but seems overly constraining now.

(I'll note that the current GitHub process for editing is more in line with one of the alternative approaches described in Section 3 than anything else.)

Given that RFC6722 is Informational, I'm not sure if it's worthwhile updating it. But someone who felt more strongly about it could prepare a bis document.

I think the main motivation behind RFC6722 was that Tao revisions were only very infrequently published, and a more lightweight process was desired. After ten years, we could certainly ask the question whether this process change was a success, and if not, what could be improved.

Thanks,
Lars

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Apr 2022 14:59:12 +0000

>    Haven't tried. However, I meant the whole web site. It would all benefit from community review.

Good grief no.

And with that, I think my contributions to this thread are done.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Apr 2022 13:19:00 -0700

On Thu, Apr 07, 2022 at 4:50 PM, Brian E Carpenter <
[email-masked]> wrote:

> RFC6722 being informational, it isn't a rule, so I urge the IESG to put
> this out for community review. That can only make it better.
>

I'll note that, even if RFC6722 were a "Standards Track With A Cherry On
The Top" document, what it says is:
"The Tao has traditionally been an IETF consensus document, which means
that the IESG has had the final say about what the Tao contained before it
was sent to the RFC Editor.  Thus, the IESG should have final say regarding
what the Tao says when it is a web page."

I read that as "it used to be a consensus document, and the IESG had final
say. As a web-page the IESG still has final say", with an implication that
the same sort of review would continue to be done.  There is nothing that
says that the IESG should do the review on our own, nor that we cannot or
should not ask the community, just that the final say/approval is the
responsibility of the IESG.

When it used to be published as an IETF consensus document, the normal
process would have been for the IESG to ask the community to review it (by
doing a last-call). I don't think that we can use the current tooling to do
a last-call of a web-page/site/something other than a draft, but it does
seem like we should be able to do something close enough by sending mail —
something like:

---
The IESG has received a request from the editor of the Tao to consider the
new version: <here>

For background, RFC6722 - Publishing the "Tao of the IETF" as a Web Page (
https://www.rfc-editor.org/rfc/rfc6722.html) describes the process by when
the Tao of the IETF is edited and published as a webpage.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2022-04-15. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

----

Actually, I personally think that the Tao itself should be still published
as an RFC, which can then be prettied up into "glossy pictures with the
circles and arrows and a paragraph on the back of each" and posted on the
website, but that's just my personal view - I don't really know the history
behind RFC6722, and so I don't know why we moved away from that model.

W

> I would ask though that going forward, we find a way for the IESG to
> review just the changes to the Tao again - that is how we usually evaluate
> "bis" documents. ADs don't have much time, and reviewing a diff is much
> faster than reviewing an entire document.
>
> FWIW, I recommend that going forward, the IESG doesn't review this
> document, as it doesn't officially review the rest of the website either.
>
> And there's the bug. Not only the lack of IESG review, but also the lack
> of community review, of our face presented to the world.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Apr 2022 14:17:42 +1200

Hi,

At https://www.cs.auckland.ac.nz/~brian/Diff-oldSplit.md-Tao.md.htm is a sort-of diff between the markdown version of the current (old) Tao and the proposed new one.

To make this possible, I ran the old markdown file through a little Python script that splits and rewraps the file so that rfcdiff can use it. The 
script (a) attempts to find lines in the new Tao that also exist in the old Tao and ensure that they start a new line, and (b) otherwise simply wraps the old Tao at column 72.

I also had to manually split a few lines that my script coughed on, and a 
few lines in Tao.md that were not actually wrapped at 72.

I hope this helps a bit. Rich is right, though, that one has to review the whole text, not just diffs.

I volunteer to do a review, but it will take some days...

Regards
    Brian Carpenter

On 09-Apr-22 08:19, Warren Kumari wrote:
> 
> 
> 
> 
> On Thu, Apr 07, 2022 at 4:50 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     But I wasn't wrong. I think RFC6722 was very wrong not to require IETF review of updates to the Tao, especially for a massive update like this one. It's quite unreasonable to put that extra load on the IESG alone. 
RFC6722 being informational, it isn't a rule, so I urge the IESG to put this out for community review. That can only make it better.
> 
> 
> I'll note that, even if RFC6722 were a "Standards Track With A Cherry On The Top" document, what it says is:
that the IESG has had the final say about what the Tao contained before it was sent to the RFC Editor.  Thus, the IESG should have final 
say regarding what the Tao says when it is a web page."
> 
> I read that as "it used to be a consensus document, and the IESG had final say. As a web-page the IESG still has final say", with an implication 
that the same sort of review would continue to be done.  There is nothing that says that the IESG should do the review on our own, nor that we cannot or should not ask the community, just that the final say/approval is the responsibility of the IESG.
> 
> When it used to be published as an IETF consensus document, the normal process would have been for the IESG to ask the community to review it (by doing a last-call). I don't think that we can use the current tooling to do a last-call of a web-page/site/something other than a draft, but it does seem like we should be able to do something close enough by sending mail — something like:
> 
> ---
> The IESG has received a request from the editor of the Tao to consider the new version: <here>
> 
> For background, RFC6722 - Publishing the "Tao of the IETF" as a Web Page (https://www.rfc-editor.org/rfc/rfc6722.html <https://www.rfc-editor.org/rfc/rfc6722.html>) describes the process by when the Tao of the IETF is 
edited and published as a webpage.
> [email-masked] <mailto:[email-masked]> mailing lists by 2022-04-15. Exceptionally, comments may
> be sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the beginning
> Actually, I personally think that the Tao itself should be still published as an RFC, which can then be prettied up into "glossy pictures with the circles and arrows and a paragraph on the back of each" and posted on the website, but that's just my personal view - I don't really know the history behind RFC6722, and so I don't know why we moved away from that model.
> 
> W
> 
> 
> 
> 
>     Regards
>     Brian
>         And there's the bug. Not only the lack of IESG review, but also 
the lack of community review, of our face presented to the world.
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/tao-discuss <https://www.ietf.org/mailman/listinfo/tao-discuss>
> 
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2022 17:19:29 +1200

Hi,

Not having write access to the repo, it seems I can't issue a PR.
I have a branch and a PR ready to go, with a modest number of minor
fixes, if someone can authorize becarpenter.
  
Here are some points from the old Tao that I can't find in the
proposed update:

> Marshall Rose once remarked that the IETF was a place to go for "many	 		
> fine lunches and dinners".

This statement from the old Tao has disappeared. I think that's a shame,
but to restore it, some explanation would have to be added.

> WG chairs are advised to participate in the WG chairs lunch mid-week...

That doesn't seem to be mentioned any more. Was that intentional?

> However, some WG chairs never manage to get their WG to finish,...

This topic seems to have vanished. Do we want to pretend it never
happens?

> Some Working Groups have complex documents or a complex set of documents	 		
> (or even both)...

Ditto. But it leads to those terrible AUTH48 delays. Do we want to pretend
that never happens either?

> If a participant makes significant contributions, the document editor or
> chair can invite the participant to become a co-author or co-editor, ...

This point seems to have got lost too.

Regards
    Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Apr 2022 13:44:51 +0000

If that is necessary, it would have to be Neils or maybe Greg.  I don't have any permissions.  I don't think I was "added" to the repository, and I don't recall asking for permission to make a pull request.  You sure?

>    but to restore it, some explanation would have to be added.

Are you sure about the reference?  The only place I could dig up was a reference to Carl Maladum's travelogue. I was also told that it was about ITU/ISO meetings, as a pejorative comment that this was their main purpose.  Perhaps it shows up in Marshall's "The Open Book" or n the "Beep" book, but I don't have those any more.  Maybe someone else could check. I also think without context it makes no sense, and is an amusing (perhaps cynical) comment not appropriate for a newcomer's doc.

>    That doesn't seem to be mentioned any more. Was that intentional?

Yes, because WG chairs aren't newcomers.

    happens?

What was the last time it happened, PKIX?  I don't think it's needed in this informal introduction to the IETF and its processes.

Longer documents take longer to prepare.  Kinda obvious, no?

>    This point seems to have got lost too.

Not "seems" :)  Yes it was removed.

An overall comment on your feedback.  You can't have an informal document *intended for newcomers* that is comprehensive and covers every nook and cranny of IETF history and procedures.  For example, one of the most important take-aways in Section 4 is the preparation section, which says "[they] are explicitly not for education" and read the documents first.  Discussion of authorship is in the noise compared to that.

Of course, this is my opinion.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Apr 2022 09:08:52 +1200

> If that is necessary, it would have to be Neils or maybe Greg.  I don't have any permissions.  I don't think I was "added" to the repository, and I don't recall asking for permission to make a pull…

I'm sure of nothing when using gh, but GitHub Desktop on Windows told me I had to be authorized to publish a branch and issue a PR. Maybe I'm doing it wrong.

> Are you sure about the reference?  The only place I could dig up was a reference to Carl Maladum's travelogue. I was also told that it was about ITU/ISO meetings, as a pejorative comment that this…

I think the original citation is Marshall T. Rose., 1990, "The open book: a practical perspective on OSI", Prentice-Hall, Inc., USA.

"A Goer attends meetings to deal with weighty political issues, travel, and have many fine lunches and dinners..."  (Google found that; I don't have the book.)

He was sneering at the difference between Goers and Doers, and I think it's never been quite rightly used in the Tao, even back to RFC1391. So let me rephrase my question: do we want to mention the difference between Goers and Doers?

> Yes, because WG chairs aren't newcomers.

OK, makes sense.

> What was the last time it happened, PKIX?  I don't think it's needed in this informal introduction to the IETF and its processes.

Not perhaps in those words, but perhaps what's really missing is a paragraph
about the appeals process and when it might be reasonable to bypass the WG
chairs and contact the AD.

> Longer documents take longer to prepare.  Kinda obvious, no?

To people with SDO experience, yes, but the issue of multiple interlocking
documents is less obvious.

> Of course, this is my opinion.

Yes, what goes in is a judgment call. I picked on things I personally would leave in.

     Brian

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Apr 2022 09:53:14 +0300

Hi,

> I'm sure of nothing when using gh, but GitHub Desktop on Windows told me I had to be authorized to publish a branch and issue a PR. Maybe I'm doing it wrong.

you need to fork the repo and commit your changes to a branch on your fork. Then you can initiate a PR based off that.

Lars

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Apr 2022 14:14:29 +0000

>   Yes, what goes in is a judgment call. I picked on things I personally would leave in.

:)

---

From: Jay Daley <[email-masked]>
Date: Thu, 14 Apr 2022 15:42:19 +0100

This whole conversation seems very messy, reflecting an underlying mess around content.  Thanlfully, we have some strands coming together to produce a new strategy for our content, which will then provide the clarity to resolve discussions like this.  What follows is my analysis of those strands and then how those relate to the Tao, starting with the less contentious issues first.  

#  Review

Review can mean a number of things.  It can mean that a document must be checked by a specific third party before it is published, which is how I think review of the Tao is being looked at, but it can also mean that content is open for anyone to review at any time, comment on and propose changes to.  For content that is going to be long-lived or small amounts of short-lived critical content then the former makes sense, but for large volumes of content that changes regularly the former becomes impossible and we have to use the latter.  The website content is clearly of that nature.  Enabling this latter kind of review requires some work:

- content published in a form/mechanism that allows for that "drive by" review and change requests, which we generally take to be GitHub.
- clear responsibilities on who reviews the change requests
- quick response to any issues and change request received   

We’ve partly achieved that for the two micro-sites we’ve recently launched - authors.ietf.org and chairs.ietf.org as those are now GitHub backed but the main website is not there yet.

#  Structure of our content

We have a huge volume of content, written by many dedicated people over many years and there are a lot of positives in that:

- lots of people voluntarily put huge effort into writing documentation
- people keep an impressive array of knowledge in working memory that they can use both to author and review
- people really care and are trying hard to provide people with useful info
- great level of detail

However, much of our content is written for "IETF participants" in the broadest sense, rather than more targeted at specific roles or tasks and that creates a range of issues.  In other words, our content often seems to assume that all participants are going to speak in WGs, author drafts, be a scribe, ask questions at the plenary, etc, etc. The issues are:

- our content often tries to cover everything that someone might possibly need to know, ever, 
- we say the same/similar thing in multiple places, which in turn makes it hard for people to find everything they need in one place
- reading and understanding our content is overwhelming, there’s rarely an easy way in
- leads to duplication as each of the locations tries to cover enough to be useful
- when things change the incorrect text has to be tracked down in multiple places, which it rarely is and so stale content abounds

What we need, and what Greg is working on with emodir, is a participant journey - a set of roles that participants take that we can flesh out and target our content at.  To be clear, I don’t mean the difference between beginner and expert, those can still be interpreted as "need to know everything" just at different levels of detail.  Instead I mean "roles" such as: mailing list lurker, in-person participant, author, wg chair, etc.  The new authors.ietf.org and chairs.ietf.org follow that principle - they aggregate all the information for one specific role into one place.  Those are not finished by any means, we don’t have a formal review team in place, there’s lots of old content around, we don’t have enough stratified content for beginners to experts, but they are getting there.

# Our style of writing

Most of our content, whoever the author, is written in a friendly open style.  Authors have made a great effort to be clear and to be inclusive.

However, despite that, there are two bad habits that fly underneath the radar. The first is to be defensive  - must do this, don’t do this, avoid that, watch out for this, and so on.  It’s as if successful participation in the IETF is predicated on learning all the rules not to break and the specific processes that must be followed to the letter.  The second is to believe that IETF memes or in-jokes have the same (or any) meaning outside the IETF as they do within.  The "many fine lunches" example from this conversation captures that perfectly - a completely meaningless phrase unless you’ve been part of the IETF for at least 10? years.

# Relating this all to the Tao

For me, the Tao incorporates both the best snd the worst of the above.  The effort and dedication that has gone into it are deeply admirable, the breadth of content is excellent and the tone is very friendly.

The problems I have with it though are not minor. The name itself, ’Tao’, is a reference too far.  Sure some of use have read "The Tao of Pooh" and get the allusion but for most people, it goes straight over their heads

More importantly though, I sincerely doubt that it is of any practical use to its intended audience - it’s far too sprawling, detailed and full of rules to be of use to a newcomer. To be quite candid, every time someone recommends to a newcomer that they read the Tao, I cringe.  What it does do is provide a useful reference for long-term participants (where else are the dot colours documented) but that’s not the intended audience.  It’s become more a series of authoritative statements that can be referenced/found individually than a flowing document.

While I admire the effort that has gone into the Tao, I think we need to move on from this style of documentation.  Replacing it with several smaller documents/sites/pages would be much more useful: "Guide to the role and structure of the IETF", "Guide to participating in IETF working groups", "Guide to making the most of IETF meetings", and so on.

Jay 

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Apr 2022 14:53:18 +0000

Very nice analysis!

>    While I admire the effort that has gone into the Tao, I think we need to move on from this style of documentation.  Replacing it with several smaller documents/sites/pages would be much more use…

Works for me.  I am happy to completely stop working on it.  Although what's on the website is seriously cringe-worthy. How that should be addressed I leave to you. I note that the RFC requiring IESG review is informational, not even BCP. Hint, hint.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 14 Apr 2022 17:03:42 +0200

I would like to note that there is some kind of tradition or cultural identity of this community connected to the Tao. However having said this, Jay, I think your analysis is right: it doesn’t serve the intended audience well and there is not one intended audience. I’m all in to reorganise all content related to participation on the webpage in a more useful way but then let’s do that and just not call it Tao anymore.

> On 14. Apr 2022, at 16:53, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> Very nice analysis!
>

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 14 Apr 2022 16:20:56 +0100

Thank you for this. I fully agree. The name 'Tao' is not very helpful and the document itself is too long (something which we tried to address). 

However, I do think it is useful to have a document people can reference which holds the main processes and procedures of the IETF which is also citeable. This would be an argument to make the Tao (which would then not be called 'Tao' anymore) an RFC and have smaller more accessible bits on the website.

Best,

Niels

On 14 Apr 2022, 16:03, at 16:03, Mirja Kuehlewind <[email-masked]> wrote:
>I would like to note that there is some kind of tradition or cultural
>identity of this community connected to the Tao. However having said
>this, Jay, I think your analysis is right: it doesn’t serve the
>intended audience well and there is not one intended audience. I’m all
>in to reorganise all content related to participation on the webpage in
>a more useful way but then let’s do that and just not call it Tao
>anymore.
>
>> On 14. Apr 2022, at 16:53, Salz, Rich
><rsalz=[email-masked]> wrote:
>> 
>> Very nice analysis!
>> 
>>>   While I admire the effort that has gone into the Tao, I think we
>need to move on from this style of documentation.  Replacing it with
>several smaller documents/sites/pages would be much more useful: "Guide
>to the role and structure of the IETF", "Guide to participating in IETF
>working groups", "Guide to making the most of IETF meetings", and so
>on.
>> 
>> Works for me.  I am happy to completely stop working on it.  Although
>what's on the website is seriously cringe-worthy. How that should be
>addressed I leave to you. I note that the RFC requiring IESG review is
>informational, not even BCP. Hint, hint.
>> 
>>

---

From: Greg Wood <[email-masked]>
Date: Thu, 14 Apr 2022 11:48:11 -0400

[Picking this point in the thread for a point not specifically related to the Tao, below]

> On 14, Apr2022, at 10:42, Jay Daley <[email-masked]> wrote:
> 

In addition to using roles/personas/journeys to understand and then deliver what a particular person needs at a point in time to achieve a successful outcome (for them), another important aspect of this approach is to validate our work with target audiences.  This requires a bit more work when they include individuals not currently active in the IETF.  For example, the “newcomers” label applied to some activities might not attract individuals who are experienced technologists but nonetheless new to the IETF and would benefit from those activities. So checking in with audiences is something that is in the mix as well.

> However, despite that, there are two bad habits that fly underneath the radar. The first is to be defensive  - must do this, don’t do this, avoid that, watch out for this, and so on.  It’s as if su…

In general, language is often baked into content in subtle ways that make it less understandable for those not familiar with the IETF.  For example, use of “draft” to mean Internet-Draft without explaining that the two terms are related.  As another example, the term “BOFs” or even “Birds of a Feather” is puzzling to outsiders as apparently it is not widely used to mean the same thing as it is in the IETF (https://en.wikipedia.org/wiki/Birds_of_a_Feather).

Identifying and tackling these subtle barriers requires concerted review and effort, and is another aspect of the work underway within emodir.

-Greg

--
Greg Wood
IETF LLC
+1-703-625-3917

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 14 Apr 2022 16:00:27 +0000

I broadly agree with what Jay has written here.

When I joined the IETF, I'm sure that someone suggested that I read the Tao.  I'm not sure how far I got through the document but not very far, or perhaps I jumped to specific sections.  I just wanted to come to a meeting and present a draft, why would I need to read such a long document!  Mostly, I turned up at the meetings, got some things right, some things wrong, learnt from my mistakes, and asked things that I didn't know (e.g., what is a bis document).  However, I did also have a large pool of colleagues to draw on, which means that I got a different experience than many newcomers.

I think that this document effectively contains a useful condensed version of the key information that a participant who gets past the "new attendee" first 5 IETFs may well want to read/understand, but of course, that means that it has the duplication of diverging content issue that Jay mentions.  However, anything that removes the requirement for participants to say read RFC 2026 and all its updates would be a win for me.

I would really like all the IETF process documents to not be RFCs/BCPs at all (RFCs/BCPs should only be the output of the IETF), but instead migrate to a set of web pages/sites, probably with a lower review barrier than full IETF consensus for most of the content.  Specifically, I think that there should be certain key steps in managing our process that must be defined with full IETF consensus, but that the implementation of that process should have a lot more freedom to evolve with how the organization, people, and people's interaction with the organization evolves over time.  Small fixes, e.g., BCP45bis, really shouldn’t need to take so much time/energy to make some pretty trivial updates.  Of course, this is way beyond the scope of this document and would probably take 2 years of arguments discussion before we even got agreement to start it, if there was any consensus at all.

Now getting off the soapbox …

In terms of helping new people coming into the IETF, I agree that having task/goal related webpages that contain the key information would be more helpful and approachable for newcomers to the IETF.

Regards,

Rob

> -----Original Message-----

> From: iesg <[email-masked]> On Behalf Of Jay Daley

> Sent: 14 April 2022 15:42

> To: [email-masked]; IESG <[email-masked]>

> Cc: Salz, Rich <[email-masked]>; Lars Eggert <[email-masked]>; Greg Wood

> <[email-masked]>; Brian E Carpenter <[email-masked]>;

> Niels ten Oever <[email-masked]>

> Subject: Re: [tao-discuss] Review Request for Possible Revision of the Tao of the

> IETF

> This whole conversation seems very messy, reflecting an underlying mess

> around content.  Thanlfully, we have some strands coming together to produce

> a new strategy for our content, which will then provide the clarity to resolve

> discussions like this.  What follows is my analysis of those strands and then how

> those relate to the Tao, starting with the less contentious issues first.

> Review can mean a number of things.  It can mean that a document must be

> checked by a specific third party before it is published, which is how I think

> review of the Tao is being looked at, but it can also mean that content is open

> for anyone to review at any time, comment on and propose changes to.  For

> content that is going to be long-lived or small amounts of short-lived critical

> content then the former makes sense, but for large volumes of content that

> changes regularly the former becomes impossible and we have to use the latter.

> The website content is clearly of that nature.  Enabling this latter kind of review

> requires some work:

> - content published in a form/mechanism that allows for that "drive by" review

> and change requests, which we generally take to be GitHub.

> We’ve partly achieved that for the two micro-sites we’ve recently launched -

> authors.ietf.org and chairs.ietf.org as those are now GitHub backed but the

> main website is not there yet.

> We have a huge volume of content, written by many dedicated people over

> many years and there are a lot of positives in that:

> - people keep an impressive array of knowledge in working memory that they

> can use both to author and review

> However, much of our content is written for "IETF participants" in the broadest

> sense, rather than more targeted at specific roles or tasks and that creates a

> range of issues.  In other words, our content often seems to assume that all

> participants are going to speak in WGs, author drafts, be a scribe, ask questions

> at the plenary, etc, etc. The issues are:

> - our content often tries to cover everything that someone might possibly need

> to know, ever,

> - we say the same/similar thing in multiple places, which in turn makes it hard for

> people to find everything they need in one place

> - reading and understanding our content is overwhelming, there’s rarely an easy

> way in

> - when things change the incorrect text has to be tracked down in multiple

> places, which it rarely is and so stale content abounds

> What we need, and what Greg is working on with emodir, is a participant

> journey - a set of roles that participants take that we can flesh out and target

> our content at.  To be clear, I don’t mean the difference between beginner and

> expert, those can still be interpreted as "need to know everything" just at

> different levels of detail.  Instead I mean "roles" such as: mailing list lurker, in-

> person participant, author, wg chair, etc.  The new authors.ietf.org and

> chairs.ietf.org follow that principle - they aggregate all the information for one

> specific role into one place.  Those are not finished by any means, we don’t have

> a formal review team in place, there’s lots of old content around, we don’t have

> enough stratified content for beginners to experts, but they are getting there.

> Most of our content, whoever the author, is written in a friendly open style.

> Authors have made a great effort to be clear and to be inclusive.

> However, despite that, there are two bad habits that fly underneath the radar.

> The first is to be defensive  - must do this, don’t do this, avoid that, watch out

> for this, and so on.  It’s as if successful participation in the IETF is predicated on

> learning all the rules not to break and the specific processes that must be

> followed to the letter.  The second is to believe that IETF memes or in-jokes

> have the same (or any) meaning outside the IETF as they do within.  The "many

> fine lunches" example from this conversation captures that perfectly - a

> completely meaningless phrase unless you’ve been part of the IETF for at least

> 10? years.

> For me, the Tao incorporates both the best snd the worst of the above.  The

> effort and dedication that has gone into it are deeply admirable, the breadth of

> content is excellent and the tone is very friendly.

> The problems I have with it though are not minor. The name itself, ’Tao’, is a

> reference too far.  Sure some of use have read "The Tao of Pooh" and get the

> allusion but for most people, it goes straight over their heads

> More importantly though, I sincerely doubt that it is of any practical use to its

> intended audience - it’s far too sprawling, detailed and full of rules to be of use

> to a newcomer. To be quite candid, every time someone recommends to a

> newcomer that they read the Tao, I cringe.  What it does do is provide a useful

> reference for long-term participants (where else are the dot colours

> documented) but that’s not the intended audience.  It’s become more a series of

> authoritative statements that can be referenced/found individually than a

> flowing document.

> While I admire the effort that has gone into the Tao, I think we need to move on

> from this style of documentation.  Replacing it with several smaller

> documents/sites/pages would be much more useful: "Guide to the role and

> structure of the IETF", "Guide to participating in IETF working groups", "Guide to

> making the most of IETF meetings", and so on.

> [email-masked]<mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Apr 2022 09:13:44 +1200

Niels, everybody,

I can see the argument for splitting the material in the Tao into more reasonable sized pieces and integrating it better into the rest of the "newcomers" material. I suspect that is best done in many smaller steps rather than in one big effort. My suggested course of action would be to complete the Tao update, which is well advanced, and then create replacement pages one at a time.

I personally think that we don't need an RFC. We have a big mess of process-related RFCs already, and I think the decision to get rid of the Tao as an RFC was the right one.

There's a great danger in "a document people can reference which holds the main processes and procedures of the IETF which is also citeable." The danger is that it will unintentionally be inconsistent with the official process. Yet again I must point to https://www.ietf.org/standards/process/informal/ . (It's out of date, by the way, and I have stopped suggesting 
updates some time ago.)

Jay and Greg are IMHO spot on in their comments.

Rob said:

> I would really like all the IETF process documents to not be RFCs/BCPs at all (RFCs/BCPs should only be the output of the IETF), but instead migrate to a set of web pages/sites, probably with a lower review barrier than full IETF consensus for most of the content.

I understand that desire, but remember that our most formal process documents are essentially legal tracts that have been checked by our lawyers and formally accepted by the ISOC Board. We really can't replace them with 
malleable web pages and any attempt to paraphrase them in simple language 
is problematic. As the informal guide says "To avoid any accidental ambiguity, this guide does not attempt to paraphrase or summarize the contents 
of listed documents."

Regards
    Brian Carpenter

On 15-Apr-22 03:20, Niels ten Oever wrote:
> However, I do think it is useful to have a document people can reference which holds the main processes and procedures of the IETF which is also 
citeable. This would be an argument to make the Tao (which would then not 
be called 'Tao' anymore) an RFC and have smaller more accessible bits on the website.
> 
> Best,
> 
> Niels
> On 14 Apr 2022, at 16:03, Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         On 14. Apr 2022, at 16:53, Salz, Rich <rsalz=40akamai.com <http://40akamai.com>@dmarc.ietf.org> wrote:
> 
>         Very nice analysis!
> 
>             While I admire the effort that has gone into the Tao, I think we need to move on from this style of documentation. Replacing it with 
several smaller documents/sites/pages would be much more useful: "Guide to the role and structure of the IETF", "Guide to participating in IETF working groups", "Guide to making the most of IETF meetings", and so on.
> 
> 
>         Works for me. I am happy to completely stop working on it. Although what's on the website is seriously cringe-worthy. How that should be 
addressed I leave to you. I note that the RFC requiring IESG review is informational, not even BCP. Hint, hint.