owners: more details and on-call

CONTRIBUTING.md

@@ -96,23 +96,23 @@ maximize the chances of your PR being merged.
   branch so that CI can pass) it is your responsibility to follow through with merging those
   changes back to master once the CI dance is done.
 
-# PR review policy for committers
+# PR review policy for maintainers
 
 * Typically we try to turn around reviews within one business day.
-* See [OWNERS.md](OWNERS.md) for the current list of committers.
-* It is generally expected that a senior committer should review every PR.
+* See [OWNERS.md](OWNERS.md) for the current list of maintainers.
+* It is generally expected that a senior maintainer should review every PR.
 * It is also generally expected that a "domain expert" for the code the PR touches should review the
   PR. This person does not necessarily need to have commit access.
 * The previous two points generally mean that every PR should have two approvals. (Exceptions can
-  be made by the senior committers).
+  be made by the senior maintainers).
 * The above rules may be waived for PRs which only update docs or comments, or trivial changes to
   tests and tools (where trivial is decided by the maintainer in question).
 * In general, we should also attempt to make sure that at least one of the approvals is *from an
   organization different from the PR author.* E.g., if Lyft authors a PR, at least one approver
   should be from an organization other than Lyft. This helps us make sure that we aren't putting
   organization specific shortcuts into the code.
 * If there is a question on who should review a PR please discuss in Slack.
-* Anyone is welcome to review any PR that they want, whether they are a committer or not.
+* Anyone is welcome to review any PR that they want, whether they are a maintainer or not.
 * Please **clean up the commit message** before merging. By default, GitHub fills the squash merge
   commit message with every individual commit from the PR. Generally, we want a commit message
   that is roughly equal to the original PR title and description.

GOVERNANCE.md

@@ -35,14 +35,23 @@
 * Monitor email aliases.
 * Monitor Slack (delayed response is perfectly acceptable).
 * Triage GitHub issues and perform pull request reviews for other maintainers and the community.
+  The areas of specialization listed in [OWNERS.md](OWNERS.md) can be used to help with routing
+  an issue/question to the right person.
+* Make sure that ongoing PRs are moving forward at the right pace or closing them.
 * Participate when called upon in the [security release process](SECURITY_RELEASE_PROCESS.md). Note
   that although this should be a rare occurrence, if a serious vulnerability is found, the process
   may take up to several full days of work to implement. This reality should be taken into account
   when discussing time commitment obligations with employers.
 * In general continue to be willing to spend at least 25% of ones time working on Envoy (~1.25
   business days per week).
-* Note that currently the above is performed by all maintainers in a best-effort/haphazard way. In
-  the future we may decide to move to an "on-call" rotation.
+* We currently maintain an "on-call" rotation within the maintainers. Each on-call is 1 week.
+  Although all maintainers are welcome to perform all of the above tasks, it is the on-call
+  maintainer's responsibility to triage incoming issues/questions and marshal ongoing work
+  forward. To reiterate, it is *not* the responsibility of the on-call maintainer to answer all
+  questions and do all reviews, but it is their responsibility to make sure that everything is
+  being actively covered by someone.
+* The on-call rotation is currently tracked in a [spreadsheet](https://docs.google.com/spreadsheets/d/11RIjkGZIe_lQQMeJbxRc-YTGuGG7yPU15Gx8uu-k2No/edit#gid=0).
+  In the future we will move to a service such as PagerDuty once CNCF sets it up for us.
 
 ## When does a maintainer lose maintainer status
 

OWNERS.md

@@ -1,22 +1,51 @@
 * See [CONTRIBUTING.md](CONTRIBUTING.md) for general contribution guidelines.
-* See [GOVERNANCE.md](GOVERNANCE.md) for governance guidelines.
+* See [GOVERNANCE.md](GOVERNANCE.md) for governance guidelines and maintainer responsibilities.
+
+This page lists all active maintainers and their areas of expertise. This can be used for
+routing PRs, questions, etc. to the right place.
 
 # Senior maintainers
 
 * Matt Klein ([mattklein123](https://github.com/mattklein123)) (mklein@lyft.com)
+  * Catch-all, "all the things", and generally trying to make himself obsolete as fast as
+    possible.
 * Harvey Tuch ([htuch](https://github.com/htuch)) (htuch@google.com)
+  * APIs, xDS, gRPC, configuration, Bazel/build, base server (startup, etc.), Python, and Bash.
 * Alyssa Wilk ([alyssawilk](https://github.com/alyssawilk)) (alyssar@google.com)
+  * HTTP, flow control, cluster manager, load balancing, and core networking (listeners,
+    connections, etc.).
 
 # Maintainers
 
 * Constance Caramanolis ([ccaraman](https://github.com/ccaraman)) (ccaramanolis@lyft.com)
+  * Rate limiting, IP tagging, HTTP routing, configuration/operational questions.
 * Jose Nino ([junr03](https://github.com/junr03)) (jnino@lyft.com)
+  * Outlier detection, HTTP routing, xDS, configuration/operational questions.
 * Dan Noé ([dnoe](https://github.com/dnoe)) (dpn@google.com)
+  * Base server (watchdog, workers, startup, stack trace handling, etc.).
 * Daniel Hochman ([danielhochman](https://github.com/danielhochman)) (dhochman@lyft.com)
+  * Redis, Python, configuration/operational questions.
 * Stephan Zuercher ([zuercher](https://github.com/zuercher)) (stephan@turbinelabs.io)
+  * Load balancing, upstream clusters and cluster manager, logging, complex HTTP routing
+    (metadata, etc.), and OSX build.
 * Greg Greenway ([ggreenway](https://github.com/ggreenway)) (ggreenway@apple.com)
+  * TCP proxy, TLS, logging, and core networking (listeners, connections, etc.).
 
 # Emeritus maintainers
 
 * Roman Dzhabarov ([RomanDzhabarov](https://github.com/RomanDzhabarov)) (rdzhabarov@lyft.com)
 * Bill Gallagher ([wgallagher](https://github.com/wgallagher)) (bgallagher@lyft.com)
+
+# Friends of Envoy
+
+This section lists a few people that are not maintainers but typically help out with subject
+matter expert reviews. Feel free to loop them in as needed.
+
+* Piotr Sikora ([PiotrSikora](https://github.com/PiotrSikora)) (piotrsikora@google.com)
+  * TLS, BoringSSL, and core networking (listeners, connections, etc.).
+* Shriram Rajagopalan ([rshriram](https://github.com/rshriram)) (shriram@us.ibm.com)
+  * Istio, APIs, HTTP routing, and WebSocket.
+* Lizan Zhou ([lizan](https://github.com/lizan)) (zlizan@google.com)
+  * gRPC, gRPC/JSON transcoding, and core networking (transport socket abstractions).
+* John Millikin ([jmillikin-stripe](https://github.com/jmillikin-stripe)) (jmillikin@stripe.com)
+  * Bazel/build.