Re: [quicwg/base-drafts] Update Contributing.md to reflect post-IESG world (#4824)

@janaiyengar commented on this pull request.

a few editorial comments

> +* Invariants
+* Transport
+* TLS
+* HTTP/3
+* QPACK
+* Recovery

Replace these with document names?

> @@ -21,12 +27,17 @@ new to this, you may also want to read the [Tao of the IETF](https://www.ietf.or

 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

+# Engaging with the QUIC community
+
+The QUIC Working Group scope of work is described in our charter and it extends beyond the development of the documents held in this repository. Anyone is welcome to contribute to the QUIC community; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work **is** a part of the QUIC Working Group.

```suggestion
The scope of work in the QUIC Working Group is described in our charter and extends beyond the development of the documents in this repository. Anyone is welcome to contribute to the QUIC Working Group; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work **is** a part of the QUIC Working Group.
```

> @@ -21,12 +27,17 @@ new to this, you may also want to read the [Tao of the IETF](https://www.ietf.or

 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

+# Engaging with the QUIC community
+
+The QUIC Working Group scope of work is described in our charter and it extends beyond the development of the documents held in this repository. Anyone is welcome to contribute to the QUIC community; you don't have to join the Working Group, because there is no "membership" -- anyone who participates in the work **is** a part of the QUIC Working Group.
+
+Before doing so, it's a good idea to familiarize yourself with our [charter](https://datatracker.ietf.org/wg/quic/about/). If you're new to IETF work, you may also want to read the [Tao of the IETF](https://www.ietf.org/tao.html).

```suggestion
Before doing so, please familiarize yourself with our [charter](https://datatracker.ietf.org/wg/quic/about/). If you are new to IETF work, you may also want to read the [Tao of the IETF](https://www.ietf.org/tao.html).
```

>  
 ## Following Discussion

 The Working Group has a few venues for discussion:

-* We plan to meet at all [IETF meetings](https://www.ietf.org/meeting/) for the foreseeable future, and hold interim meetings between them. See our [meeting materials repository](https://github.com/quicwg/wg-materials) and the [official proceedings](https://datatracker.ietf.org/wg/quic/meetings/).
+* We plan to meet at all [IETF meetings](https://www.ietf.org/meeting/) for the foreseeable future, and possibly hold interim meetings between them if required. Agendas, minutes and presentations are available in our [meeting materials repository](https://github.com/quicwg/wg-materials) and the [official proceedings](https://datatracker.ietf.org/wg/quic/meetings/).

```suggestion
* We plan to meet at all [IETF meetings](https://www.ietf.org/meeting/) for the foreseeable future, and hold interim meetings between them as required. Agendas, minutes, and presentations are available in our [meeting materials repository](https://github.com/quicwg/wg-materials) and the [official proceedings](https://datatracker.ietf.org/wg/quic/meetings/).
```

>  
-We use our [Github](https://github.com/quicwg/) issues lists to track items for discussion and
-their resolution.
+The Working Group has built consensus that is reflected in base-draft documents, which has been confirmed through the IETF Last Call and IESG review stages modulo any critical undiscovered issues. Design changes will no longer be considered unless there are severe security, deployment or implementation problems. modulo any open (or undiscovered) issues. The goal of the Post-IESG proces is to minimise changes that invalidate the accumulated consesus, which risks returning us to the pre Working Group Last Call stage of standardisation.

```suggestion
The consensus of the Working Group is reflected in the base-draft documents, which has been confirmed through the IETF Last Call and IESG review stages. The goal of the Post-IESG process is to minimize the risk of changes invalidating the established consensus in these documents. Consequently, design changes and substantial editorial changes will no longer be considered unless they relate to severe security, deployment, or implementation problems.
```

>  
-Before filing a new issue, please consider a few things:
+In this process, all required parties will discuss each design or major editorial issue and proposed resolution (ideally based upon a Pull Request that specifies the exact changes to be made). Chairs will judge consensus, labelling the issue as `has-consensus`.

For clarity, can you list the "required parties"?

>  
-* Issues should be just that; issues with our deliverables, **not proposals, questions or support requests**.
-* Please review the issues list to make sure that you aren't filing a duplicate.
-* If you're not sure how to phrase your issue, please ask on the [mailing list](https://www.ietf.org/mailman/listinfo/quic).
+### Raising Issues
+
+We will no longer consider Design changes or substantial Editorial changes unless they relate to severe security, interoperabily or deployment problems.

```suggestion
We will no longer consider design changes or substantial editorial changes unless they relate to severe security, deployment, or implementation problems.
```

> +We use our [Github](https://github.com/quicwg/) issues lists to track items for discussion and
+their resolution.

```suggestion
We will continue to use our [Github](https://github.com/quicwg/) issues lists to track items for discussion and their resolution.
```

>  
 Issues will be labeled by the Chairs as either `editorial` or `design`:

-* **Design** issues require discussion and consensus in the Working Group. This discussion can happen both in the issue and on the [Working Group mailing list](https://www.ietf.org/mailman/listinfo/quic), as outlined below.
+* **Design** issues require discussion and consensus among the Working Group, Area Director and IESG. This discussion can happen both in the issue and on the [Working Group mailing list](https://www.ietf.org/mailman/listinfo/quic), and all other relavent mailing lists.

```suggestion
* **Design** issues require discussion and consensus among the Working Group, the Area Director, and the IESG. This discussion can happen in the issue, on the [Working Group mailing list](https://www.ietf.org/mailman/listinfo/quic), or other relevant mailing lists.
```

>  
-* **Editorial** issues can be dealt with by the editor(s) without consensus or notification. Typically, any discussion will take place on the issue itself.
+* **Editorial** issues that or minor or unsubstantial can be dealt with by the editor(s) without consensus or notification. Larger editorial changes require discussion and and consensus among the Working Group, Area Director and IESG.

```suggestion
* **Editorial** issues that are minor can be dealt with by the editor(s) without consensus or notification. Larger editorial changes require discussion and and consensus among the Working Group, the Area Director, and the IESG.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4824#pullrequestreview-582991653