Reduce/restrict scope of the project?

[mmarchini]

node-core-utils has's been used to land PRs on some WGs from time to time, as well as some projects like llnode. None of those projects really need to follow nodejs/node landing flow though. Based on some comments on #469, I'm wondering if we should reduce the scope of this project to only land pull requests on nodejs/node, instead of aiming to land any pull requests on any projects in the org. This should help us reduce some complexity in the code base (such as multiple CI providers) as well as reduce frustration from trying to use it on other repositories (which always need some workaround) and allow us to filter out feature requests that are not targeted at nodejs/node (such as #373).

We would need to update some documentations to clarify that, and doing so could be considered a breaking change to the project.

[codebytere]

I personally would be in favor of demarcating scope limits along these lines for the same reasons, as well as to help ensure that decisions around what features we do and don't add (and workarounds) are more clearly enumerated.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[gengjiawen]

I would suggest reopen this.

Currently I have to maintain a fork of this to make life easier.

executing git node metadata https://github.com/nodejs/node-gyp/pull/2285
will resolve to

✖  Failed to get collaborator info from nodejs/node-gyp/README.md
Error: Couldn't find ### TSC (Technical Steering Committee) in the README
    at parseCollaborators (/usr/local/share/.config/yarn/global/node_modules/node-core-utils/lib/collaborators.js:83:11)
    at getCollaborators (/usr/local/share/.config/yarn/global/node_modules/node-core-utils/lib/collaborators.js:61:21)
    at processTicksAndRejections (node:internal/process/task_queues:93:5)
    at async PRData.getCollaborators (/usr/local/share/.config/yarn/global/node_modules/node-core-utils/lib/pr_data.js:77:26)
    at async Promise.all (index 0)
    at async PRData.getAll (/usr/local/share/.config/yarn/global/node_modules/node-core-utils/lib/pr_data.js:61:5)
    at async getMetadata (/usr/local/share/.config/yarn/global/node_modules/node-core-utils/components/metadata.js:20:3)

fixing #373 really need this.

also cc @richardlau @rvagg

[rvagg]

Yeah, I do all of node-gyp's metadata manually, that's still in my muscle memory from old-timey nodejs/node commit merging, but it does get pretty tedious and is probably one of the reasons I delay a lot of merging. Does this just need someone to do the work to enable this for alternative repos while not exposing that complexity to the common use-case of nodejs/node maintenance? That's the approach I took with branch-diff and changelog-maker -- they're made for nodejs/node by default (there's some URL inference in there if there's incomplete information) but they're also perfectly usable for any other repo if you have everything in order.