Minor doc updates (#792)

* Minor doc updates

* Update WG description

CONTRIBUTING.md

@@ -39,7 +39,7 @@ productivity and inter-personal interactions.
 ## Contributor license agreements
 
 We'd love to accept your contributions! But before we can take them, you will
-have 
+have
 to fill out the [Google CLA](https://cla.developers.google.com).
 
 Once you are CLA'ed, we'll be able to accept your pull requests. This is
@@ -75,7 +75,7 @@ To use either template, open the template and select "Use Template" in order to
 In order to contribute a feature to Istio you'll need to go through the following steps:
 
 - Discuss your idea with the appropriate [working groups](WORKING-GROUPS.md) on the working
-group's mailing list.
+group's Slack channel.
 
 - Once there is general agreement that the feature is useful, create a GitHub issue to track the discussion. The issue should include information
 about the requirements and use cases that it is trying to address. Include a discussion of the proposed design and technical details of the
@@ -84,14 +84,14 @@ implementation in the issue.
 - If the feature is substantial enough:
 
   - Working group leads will ask for a design document as outlined in the previous section.
-  Create the design document and add a link to it in the GitHub issue. Don't forget to send a note to the
+  Create the design document and add a link to it in the GitHub issue. Don't forget to send a Slack to the
   working group to let everyone know your document is ready for review.
 
   - Depending of the breath of the design and how contentious it is, the working group leads may decide
   the feature needs to be discussed in one or more working group meetings before being approved.
 
-  - Once the major technical issues are resolved and agreed upon, post a note to the working group's mailing
-  list with the design decision and the general execution plan.
+  - Once the major technical issues are resolved and agreed upon, post a note to the working group's Slack
+  with the design decision and the general execution plan.
 
 - Submit PRs to [istio/istio](https://github.com/istio/istio) with your code changes.
 

RELEASE_MANAGERS.md

@@ -1,5 +1,17 @@
 # Current Release Managers
 
+## 1.16
+
+* [Daniel Hawton](https://github.com/dhawton)
+* [Ziyang Xiao](https://github.com/ZiyangXiao)
+* [Tong Li](https://github.com/litong01)
+
+## 1.15
+
+* [Sam Naser](https://github.com/Monkeyanator)
+* [Daniel Hawton](https://github.com/dhawton)
+* [Ziyang Xiao](https://github.com/ZiyangXiao)
+
 ## 1.14
 
 * [Greg Hanson](https://github.com/GregHanson)

WORKING-GROUP-PROCESSES.md

@@ -19,8 +19,8 @@ Istio working groups are organizations responsible for the design and implementa
 Working groups operate with a fair amount of autonomy within the broader scope of the project. They tend to be long-lived, representing major
 initiatives over Istio’s lifetime.
 
-Some working groups focus on specific technologies. For example, the Policy and Telemetry working group primarily focuses on Mixer. Other
-working groups are cross-cutting in nature such as the Performance and Scalability working group.
+Some working groups focus on specific technologies. For example, the Extensions and Telemetry working group focuses on WebAssembly based
+extensibility and extensions for features such as Rate Limiting, Tracing, Monitoring, Logging.
 
 The [Technical Oversight Committee](TECH-OVERSIGHT-COMMITTEE.md) (a.k.a. TOC) is responsible for the Istio project as a whole. It sets the overall direction
 of the project, helps make crosscutting architectural decisions, helps establish and dissolve working groups, and helps ensure all working
@@ -78,7 +78,7 @@ Congratulations, you now have a fully formed working group!
 ### Dissolving a working group
 
 Some working groups are ephemeral or naturally reach the end of their useful life. Working group leads can petition to dissolve their working
-groups by posting to  [technical-oversight-committee](https://discuss.istio.io/c/technical-oversight-committee). The
+groups by posting to [technical-oversight-committee](https://discuss.istio.io/c/technical-oversight-committee). The
 technical oversight committee also reserves the right to dissolve or recharter working groups over time as necessary.
 
 ## Leads
@@ -92,22 +92,22 @@ description of a lead’s role and requirements.
 
 Leads are responsible for running a working group. Running the group involves a few activities:
 
-* **Meetings**. Prepare the agenda and run the regular working group meetings. Ensure the meetings are recorded, and properly archived
-on YouTube.
+* **Meetings**. Help with running the combined working group meetings. Be sure to attend the meeting if there is an agenda item
+for your workgroup. Ensure the meetings are recorded, and properly archived on YouTube.
 
-* **Notes**. Ensure that meeting notes are kept up to date. Provide a link to the recorded meeting in the notes. The lead may delegate
-note-taking duties.
+* **Notes**. Ensure that meeting notes are kept up to date. The lead may delegate note-taking duties.
+Provide a link to the recorded meeting in the notes.
 
 * **Roadmap**. Establish **and maintain** a roadmap for the working group outlining the areas of focus for the working group over the next
 3 months.
 
-* **Report**. Report current status to the main community meeting every 6 weeks.
+* **Report**. Report current status to the TOC meeting every as appropriate.
 
 ### Be open
 
 The community design process is done in the open. Working groups should communicate primarily through the public
-working group mailing list and meetings, through design documents in the working group’s folder, through GitHub issues, and GitHub PRs.
-Avoid private emails and/or meeting when possible.
+working group Slack channel and meetings, through design documents in the working group’s folder, through GitHub issues, and GitHub PRs.
+Avoid private emails and/or meetings when possible.
 
 ### Making decisions