As discussed in TOC meeting rationalize the owners (knative#8029)

* As discussed in TOC meeting rationalize the owners

- create TOC and WG-LEAD lists and populate with up to date members
- use those aliases to populate serving-wg-leads alias
- use that alias as the top level approver

With expanded powers come expanded responsibilities.

The gentlemen's agreement is that you don't approve sustantial
changes to the part of the codebase that you're not in the OWNERS
file yet.

E.g. Victor would not approve Service API surface change and Dave
won't approve the change to the logic of autoscaling algorithm.

* use only names in aliases

OWNERS

@@ -1,7 +1,4 @@
 # The OWNERS file is used by prow to automatically merge approved PRs.
 
 approvers:
-- evankanderson
-- mattmoor
-- mdemirhan
-- vaikas
+- serving-wg-leads

OWNERS_ALIASES

@@ -1,29 +1,42 @@
 aliases:
   serving-api-approvers:
-  - dgerd
   - dprotaso
   - markusthoemmes
   - mattmoor
   - tcnghia
   - vagababov
   serving-api-reviewers:
-  - dgerd
   - dprotaso
   - markusthoemmes
   - mattmoor
   - tcnghia
   - vagababov
 
+  toc:
+  - evankanderson
+  - grantr
+  - markusthoemmes
+  - mattmoor
+  - tcnghia
+
+  wg-leads:
+  - dprotaso        # API
+  - markusthoemmes  # Scaling
+  - mattmoor        # API
+  - mdemirhan       # Network
+  - tcnghia         # Network
+  - vagababov       # Scaling
+
   # TOC + WG leads
   serving-wg-leads:
-  - evankanderson  # TOC
-  - mattmoor       # TOC/Serving
-  - vaikas         # TOC
-  - dprotaso       # Serving
-  - markusthoemmes # Scaling
-  - mdemirhan      # Networking
-  - tcnghia        # Networking
-  - vagababov      # Scaling
+  - dprotaso        # API
+  - evankanderson   # TOC
+  - grantr          # TOC
+  - markusthoemmes  # Scaling/TOC
+  - mattmoor        # API/TOC
+  - mdemirhan       # Network
+  - tcnghia         # Network/TOC
+  - vagababov       # Scaling
 
   autoscaling-approvers:
   - markusthoemmes