doc: add .github to CODEOWNERS

[Trott]

Add .github directory to CODEOWNERS file.

Checklist

• documentation is changed or added
• commit message follows commit guidelines

[Trott]

Lite CI: https://ci.nodejs.org/job/node-test-pull-request-lite/709/

[vsemozhetbyt]

Node.js Collaborators, please, add 👍 here if you approve fast-tracking.

[apapirovski]

@Trott sorry, this needs a rebase due to the other CODEOWNERS changes landing.

[jasnell]

btw.. it's not clear if the CODEOWNERS file is actually working at this point... need to do more verification...

[Trott]

btw.. it's not clear if the CODEOWNERS file is actually working at this point... need to do more verification...

@jasnell Seems to be working as expected. What's makes it not clear that it's working in your view?

[Trott]

@apapirovski Rebased.

[jasnell]

What makes it not clear ...

For example, the @nodejs/fs team did not appear to be requested for review automatically in the various fs related PRs I just opened.

[Trott]

Lite CI: https://ci.nodejs.org/job/node-test-pull-request-lite/717/

[Trott]

For example, the @nodejs/fs team did not appear to be requested for review automatically in the various fs related PRs I just opened.

@jasnell Per https://help.github.com/articles/about-codeowners/: "The people you choose as code owners must have write permissions for the repository." I very much doubt that GitHub expands the team and checks the permissions of every person on the team. So the nodejs/fs team will never be requested for review automatically, if I'm right about that. Again, if I'm right, choices are:

• List people as individuals in CODEOWNERS (seems undesirable to me)
• Add the team as having write privileges to the repo (also undesirable IMO as there's no reason to think that group should be limited to current Collaborators)
• Use CODEOWNERS as documentation for groups like that rather than automation (seems pointless to me)
• Shrug and remove entries for teams other than TSC and call it a mostly-failed experiment. (No shame in failed experiments. If all your experiments succeed, you're not experimenting enough.)

[Trott]

@jasnell My speculation is confirmed at https://gh.neting.ccmunity/t5/How-to-use-Git-and-GitHub/CODEOWNERS-works-with-users-but-not-teams/m-p/4991#M1612:

It's not enough for all the members to have write access, you need to grant write access to the actual team.

As I say above, I don't think we actually want to do that (and certainly not without the TSC discussing it). So I think we're stuck with a CODEOWNERS file that works for TSC assignments and not much else.

Paring down the CODEOWNERS file to just TSC might actually be a good start.

We can then add individuals for certain files or areas. I'm not sure that will actually work for the same reason teams don't work. (Does an individual need to be listed in the Settings as having write permission or is it enough that they're a member of a team with Write permission? We'll find out, I guess.)

I know I said previously that I thought we probably don't want to add individuals, but thinking about it more, it's probably OK. If an individual is no longer a Collaborator, their entry in CODEOWNERS will be ignored (because they no longer have write access to the repo).

[richardlau]

I very much doubt that GitHub expands the team and checks the permissions of every person on the team.

Confirmed: https://gh.neting.ccmunity/t5/How-to-use-Git-and-GitHub/CODEOWNERS-works-with-users-but-not-teams/m-p/4991/highlight/true#M1612

[jasnell]

Boo... that's unfortunate. I'd say let's leave the CODEOWNERS file as it is and have a discussion with github about the limitations here. It may be worthwhile feedback for them.

[Trott]

Landed in 2183b25