Metadata locations

[gsnedders]

We currently have three different sets of metadata:

1. The META.yml files in web-platform-tests/wpt, which contain directory-level metadata, with two keys: spec (a URL) and suggested_reviewers (a sequence of GitHub usernames).
2. The WEB_FEATURE.yml files in web-platform-tests/wpt, which map tests in a directory to Web Features.
3. The META.yml files in web-platform-tests/wpt-metadata, which:
   1. Map tests in a directory to labels,
   2. Map tests in a directory, or subtests within a test in a directory, to (potentially "product" specific) URLs, intended to link to bugs.

This feels like we have entirely too many locations for metadata, and there's been enough times when people haven't realised that there is metadata for something somewhere, just in a different place. And least to me, it isn't clear what benefit we gain from this current duplication.

At first glance, "spec" and "web feature" seem kinda similar, and "web feature" and "label" seem kinda similar.

The Web Features RFC cites these meeting notes for the decision to put them in a separate file to the pre-existing META.yml, but it's not obvious why that decision was made.

When it comes to the wpt-metadata data, the labelling data often ends up having to have paired WPT PRs when test changes are made to Interop tests; though keeping the product-specific data out of the main repo seems sensible, even if it is still tied to the main repo's revision.

I don't know if there's appetite to try and merge some of these files, but maybe we should consider it for the sake of discoverability?

[jgraham]

For web features I think the reasoning is that it's experimental and should be easy to revert. At this point I'd say the web features metadata isn't adding much value (it isn't reliable enough for the purported use cases, and there doesn't seem to be a realistic path to make it so.

I'd really like to move the data in wpt-metadata in-tree, but that is a lot of work, since it requires changes to consumers. I suppose we could move it in-tree and then make a one-way export to the wpt-metadata repo to ease the transition, but that would still require changes to wpt.fyi and the gecko wpt sync (for example), which currently expect to be able to open PRs against the wpt-metadata repository.