create a `issue-triage` team

[gireeshpunathil]

this issue is to:

• propose a issue-traige team to contain the triage team members (ref: https://github.com/nodejs/node/blob/master/GOVERNANCE.md#triagers and https://github.com/nodejs/node/pull/35153#issuecomment-691668773 ) with "triage" access for the node and help repos, and the usual "write" access to the moderation repo
• discuss and gather consensus
• and create one
• pls add +1 / 👍 to this issue if you concur, or else pls share views!

EDIT: added the traige access info.

[Trott]

+1 👍

[Trott]

I think issue-triage should be given "triage" access for the node and help repos, and the usual "write" access to the moderation repo.

[gireeshpunathil]

thanks @Trott , inline edited the comment with that info

[mmarchini]

cc @nodejs/tsc @nodejs/community-committee

[MylesBorins]

One question. Will the triage team be able to kick of CI or land commits via labels?

I think there are two questions here

1. What are the default permissions
2. What behavior do we see as desirable

I don't have super strong opinions just yet, aside from assuring that we are intentional

[mhdawson]

+1

[gireeshpunathil]

@MylesBorins - thanks, I don't know the answer to that. Of course the github documentation does not cover that. Looks like the build team, who made the scripts for the CI and LAND workflows would know.

/cc @nodejs/build @nodejs/automation

[gireeshpunathil]

regarding desired levels: I am fine with permissions for those 2 actions to be granted to triagers, with a reasoning of more permissive than inhibitive, leading to more empowerment

but open to discussions.

[mmarchini]

Triagers will be able to start CI and land PRs using the commit queue.

[gireeshpunathil]

so that means now the only outstanding question is: are we good to grant these permissions (default github permissions plus CI and land permissions) to triagers?

[nschonni]

Looks like you could potentially have a github action to guard those labels by doing some inspection on the sender https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#label Still possible for the cron job to pick up the label before that action removes it, but that might not really be a concern you have

[mmarchini]

FWIW this is an issue that was raised before landing the commit queue, and the consensus back then was that it's not an issue: https://github.com/nodejs/TSC/issues/907#issuecomment-672373221

[mmarchini]

I guess the only question I have is: do we have a clear process for folks to become triagers (like we have for collaborators)? Groking our policy I couldn't find it.

[gireeshpunathil]

the process is outlined here: https://github.com/nodejs/node/blob/master/doc/guides/contributing/issues.md#triaging-a-bug-report

the key is: Anyone with a reasonable understanding of Node.js programming and the project's GitHub organization plus a few contributions to the project (commenting on issues or PRs) can apply for and become a triager. Open a PR on the README.md of this project with: i) a request to be added as a triager, ii) the motivation for becoming a triager, and iii) agreement on reading, understanding, and adhering to the project's Code Of Conduct.

[gireeshpunathil]

@mmarchini - are you familiar with the process of creating teams, and if so can you make this? (I haven't tried before, don't want to make mistakes.) thanks!

[gireeshpunathil]

nvm, I attempted one here https://github.com/orgs/nodejs/teams/issue-triage

pls have a look and let me know , especially therepositories attribute.

[MylesBorins]

general permissions look good. Do we want this to be a subteam?

[gireeshpunathil]

@MylesBorins - thanks.

Do we want this to be a subteam?

tbh, no idea. tradeoffs of being / not being a suteam?

[mmarchini]

@MylesBorins a subteam of which team? It can't be a subteam of collaborators since triagers don't necessarily have commit access.

[gireeshpunathil]

purpose met - sub team created, closing