discussion: put subsystem, team and label metadata in file(s) in this repo

[joyeecheung]

Right now there are multiple places that somewhat capture the label and subsystem metadata in this repo:

In core-validate-commit:

https://github.com/nodejs/core-validate-commit/blob/4e64157b6a87267fd4b9f0598159eeb968e04e21/lib/rules/subsystem.js#L5-L68

In github-bot:

https://github.com/nodejs/github-bot/blob/8d4b7199f871fe37f2528520e79a0d8568960184/lib/node-labels.js#L5-L139

And of course the source of truth about labels is https://github.com/nodejs/node/labels

There is also discussion about automation of pinging teams, similar to how the now-removed CODEOWNERS file used to work (because the GitHub implementation didn't actually work for us). But to implement any of that, we will need this information actually written down somewhere in some format

https://github.com/nodejs/automation/issues/27

Also related: Store list of collaborators and TSC in a JSON file https://github.com/nodejs/node/issues/23623

Note that one of the reasons that CODEOWNERS is removed is that the pinging only worked for teams who have write access to this repo, and in core there are two type of groups we need to ping: WGs or teams whose members may or may not have write access but need to be informed (observers), and collaborators who tend to review the files more often than the others (owners).

At a glance, I think the information is basically a mapping of file_pattern -> (subsystem, owners[], observers[], labels[]) - but maybe there is more e.g. precedence and hierarchy. (note that subsystems are not equivalent to labels, as labels can be dont-land-*)

I propose to put this information in this repo, and then we could figure out how to utilize it for automation - but it still has value even just as a general dictionary to look things up, even for humans.

On the automation's side - we could use it to ping people (or just suggest to you who to ping without actually pinging them so you don't accidentally create noise), to request reviews, to check reviews when landing PRs, to make sure the labels and their descriptions are not out of date, to dynamically introduce new subsystems in commit messages (to validate) etc. More importantly we can introduce new meta information and remove them by submitting PRs to these meta files instead of updating all the relevant projects (e.g. the bot doesn't know about all the files and the dont-land labels there are really out of date. If it just grabs the information from the master, we are more likely to keep the information up-to-date).

I don't know if there is a particularly good format, maybe a JSON or YAML? Or a variant of the removed CODEOWNERS (see https://github.com/nodejs/node/pull/21161) file?

For reference, WPT uses a META.yml, v8 uses OWNERS, both seem to be home-grown files placed in different level of directories.

[Trott]

Related issue: https://github.com/nodejs/node/issues/23749

[jasnell]

Does this need to remain open?

[mmarchini]

I'm in favor of keeping this open, as it is something that we should do.

[jasnell]

Given that we have CODEOWNERS functioning now, does this still need to remain open?

[mmarchini]

@jasnell I think this is a separate issue and should still be worked on (the "team" part is somewhat covered by codeowners, but not subsystem and labels)

[joyeecheung]

I wonder if we can put all these into a JSON file in custom format and then use this to generate the CODEOWNERS file and the collaborator list in the README, although this may be a little bit confusing for people touching them for the first time (maybe we can use comments to remind them)

[mmarchini]

I thought about that, but the labels script has a bunch of extra logic on top of the regex definitions, which makes decoupling harder.