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

@martinthomson commented on this pull request.

I think that you probably want to include more information on what someone might do if they have a non-critical problem or suggestion for improvement.

That is, we should be encouraging people to discuss their problems and ideas with the working group with the idea that they work toward new extensions to the protocol rather than changes to these documents.

Beyond that, there is a ton of stuff here that can be cut entirely.  Lots of this is process we invented during earlier stages of the work that no longer applies.

>  
-Before doing so, it's a good idea to familiarize yourself with our current [issues list](https://github.com/quicwg/base-drafts/issues) and [charter](https://datatracker.ietf.org/wg/quic/about/). If you're
-new to this, you may also want to read the [Tao of the IETF](https://www.ietf.org/tao.html).
+* Invariants
+* Transport
+* TLS
+* HTTP/3
+* QPACK
+* Recovery
+
+**All of the documents have now passed IESG review stage. We will no longer consider Design changes or substantial Editorial changes unless they relate to severe security, interoperabily or deployment problems. See [Post-IESG Process](#post-iesg-process) below for further information** 

Maybe instead:

> All of the documents have been approved for publication as RFC. ...

That might be more accessible to people who aren't familiar with our processes.

>  
-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.

I would drop the two "modulo..." bits.  Especially the second.

>  
-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`.

I think that you want to just say "Any change will be subject to careful review and discussion, which might involve the editors, chairs, working group, and our area director."  Leaving aside the question of how much discussion, which we might vary based on what the change is.

The `has-consensus` piece can go.

>  
 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.

Oxford comma.

And again, I would say **Any issue** here.

>  
-* **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.

 The open design issues in the issues list are those that we are currently discussing, or plan to discuss. They can be discussed on the mailing list or the issue itself.

We have none of these, so I think it would be best to avoid mention of it.

> -The late-stage process attempts to reflect the Working Group's current consensus in the drafts; the latest draft reflects that consensus, modulo any open (or undiscovered) issues. The goal for a late-stage draft is to reduce unnecessary design changes in the protocol, thereby aiding reviewers and assuring that the drafts accurately reflect consensus.
-
-In this process, the Working Group will discuss each design issue, and the Chairs will judge consensus, labelling the issue as `has-consensus` (ideally based upon a Pull Request that specifies the exact changes to be made).
-
-Only after that will the change be merged and the issue be closed.
-
-The drafts currently in the late stage are:
-
-* Invariants
-* Transport
-* TLS
-* HTTP/3
-* QPACK
-* Recovery
-
-![diagram of the late stage workflow](workflow.png "Late Stage Workflow")

You can delete this diagram here too.

>  
-* 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

I think that you might want to say outright that this repo is closed for business and that new issues should be first discussed by the working group.  Then set expectations: say that we will only consider the most serious issues that might jeopardize the successful deployment of QUIC, such as serious security flaws or bugs without workarounds.

-- 
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-582992234