ietf/tao

The Tao of the IETF

tao's Issues

Editing method should follow the README

Specifically:

The main branch always has the current working copy. Pull requests should be based off main and are merged into main when they are accepted.

When the current tip of main is published to the IETF website, it is pushed to the published branch, and a new tag in YYYY-MM-DD format is created based on the publication date.

Comparing the main and published branches hence always shows all currently unpublished differences.

This would really make IESG reviews easier, because we could look at the diff between these branches.

Should we restructure the Tao?

I'm wondering if it would make more sense for newcomers to kind of reverse the order od the doc, still starting with the mission but then talk about how to contributie, the meeting, wg sessions, mailing lists, and the at the end the more formal stuff like IESG and ISOC. I didn't check if that is an easy change in the sense that currently later sections might assume pre-knowledge from previous sections. However, I guess often people might anyway only read parts of the Tao and therefore working with forward references if really needed shouldn't be too bad

update RSE and RSOC references

A specific example is that in section 3.6, the RSE dot is no longer applicable.

Broader updates should be considered as the RFC Editor situation evolves through the RFC Editor Future Development (rfcefdp) program.

Leverage more markdown where we can

The Tao is turned from markdown into HTML by the wagtail plugin. We should leverage more of its (limited?) capabilities in the document, such as

• Markdown links not a and href tags
• Auto-numbering of the table of contents and items
• Better URL referencing, the [foo](https://foo...) or the equivalent that is supported, if anything.

"We have lost important information" from Brian Carpenter

This is from email Brian Carpenter sent to wgchairs and rfc-interest, that has become a separate sub-thread. You can find a copy of his message (and full context) here: https://mailarchive.ietf.org/arch/msg/wgchairs/HqGXYC8pT5HGao4u3BRKJqjh_es/

    > I can't reduce this to a PR. It seems to me that the proposed new text 
    > for the Tao has lost some very important parts of the old text. It 
    > doesn't state that I-Ds expire after 6 months (which they still do, 
    > unless we amend RFC 2026), it doesn't underline that "They are most 
    > definitely not standards" and it doesn't state that they must only be 
    > cited as "work in progress". There's no need to quote BCP 9, but I think 
    > the points should be made.
    > 
    > Also, BTW, as well as mentioning the optional Privacy Considerations, 
    > why not mention the optional Implementation Status section (RFC7942 = 
    > BCP 205)?

Section 3.12.2 seems to be trying to deter network operator participation

Section 3.12.2 starts with

"Running a network is hard enough without having to grapple with new protocols or new versions of the protocols with which you are already dealing."

This is more of a deterrent than a welcoming statement. The second paragraph has a lot of good reasons for network operators to participate, which should be emphasised.

Fix RFC and BCP links

Links to RFC's and BCP documents should point to the rfc-editor.org site, not tools.ietf.org

Update references to EDU

especially in section 3.11, e.g.:

s/EDU/EMODIR

Perhaps this repo should be archived?

And no longer pinned on https://github.com/ietf given the publication of RFC 9592?

Using branches and tags

I'd suggest that the "main" branch (which we should rename "master" to, btw) be the main working branch going forward.

We should create a second branch ("published" or something like that) that we push the current tip of "main" to when that gets published on the website.

We should also create a revision and/or date tag when a new version is published.

This would allow us to get rid of Tao_Current.txt.

We should also get rid of Tao.html - what is that for anyway?

Update 3 to reflect current online meetings

Section 3 assumes in person meeting as the usual meeting participation mode so the text should be updated throughout to reflect the current online approach.

Since online meetings are likely to be the norm for most people, with the situation evolving, it might be worth considering how to update this section more often.