In terms of categorization (and not teams), this looks like something that belongs in Internals>Metrics.

Yes, there is overlap between the team name and component name, but we don't intend this as a team component.

We think this component should be separate from Internals>Metrics for a few reasons:
- This will cover the mechanisms by which features are exposed to the web platform. The intent is to explicitly represent the functional area of web platform surface area, which has fallen through the cracks in the past.
- It should mostly be web-developer invisible, and thus is under Internals. This will be visible to and focused on Blink developers, so we think it should be under Blink
- Clearly, some metrics are included (i.e. UseCounters), but are only a part of the story. The metrics here make use of the infrastructure covered by Internals>Metrics (i.e. UMA, UKM). However, we think they are functionally separate. 

For full context, see the Feature Control team charter, including comments about the interaction/overlap with other teams/areas:
https://docs.google.com/document/d/1RBbEFZ46Bws8eiPlzxFjRE5WI8oIBnDQXHqM_S23xmQ/

Ping. Could I get an update on this request?

Yeah things like webexposed tests, RuntimeEnabledFeatures, etc. have nothing to do with "metrics".  So even if we put UseCounters in Internals>Metrics, we'd still need somewhere to put these "bugs in the internal infrastructure used to enable/disable and track the APIs we exposed to the web".  I understand the desire to avoid having team-specific labels, but we also create teams around related code so it's not really a co-incidence that the group of code we've chosen for a team is also a good group of functionality for an Internals> label ;-)

Hi, I believe we've answered the question about the best location for this component. Anything outstanding here to create the component?

Let's figure out a component name that works under the root Internals component. 
Subcomponent replicating common top level structures makes traversing the hierarchy less predictable.

Agreed, Internals>Metrics may not make sense.  Perhaps just Internals>FeatureControl.

We'd be fine with Internals>FeatureControl. We don't expect web developers to be filing bugs in this area via the new bug wizard, so it shouldn't matter if the component doesn't show up there.

However, I believe this means that any bugs in the component will be excluded from the general web platform bug reporting, dashboards, .etc.

sshruthi@, am I understanding that correctly? If so, how important is that Feature Control bugs live somewhere under a Blink component?

Let's do what makes sense from a reporter's perspective. I will try and figure out how to capture those in the dashboards. I went ahead and created the component and added Jason as admin, could you please add a description?

Great, thanks! Description added.