Nominating Richard Lau

[Trott]

Per the Charter:

Changes to TSC membership should be posted in the agenda, and may be suggested as any other agenda item.

I'd like to nominate Richard Lau. He has been a longstanding invaluable contributor. Excellent code reviews. Top-notch communicator. Irreplaceable resource for Build WG and Releasers. Great code contributions too, of course. Long overdue, in my opinion.

@nodejs/tsc

[nschonni]

Not sure if this will be over number max number of seats for IBM #829 (comment). Just triggered the memory of the previous discussion

[Trott]

Not sure if this will be over number max number of seats for IBM #829 (comment). Just triggered the memory of the previous discussion

The charter indicates the maximum is one-fourth. With Richard added, we would have 22 members, so a single employer could have up to 5 members.

IBM/RedHat currently has 3 (Beth, Gireesh, Michael).

I believe they previously had 5 (the current members, plus Sam Roberts and Dan Bevenius) but that is no longer the case.

So we're all good there, I think.

[mmarchini]

+1

[BridgeAR]

+1

[joyeecheung]

+1

[apapirovski]

+1

[gireeshpunathil]

+1

[targos]

+1

[mcollina]

+1

[ronag]

+1

[aduh95]

+1

[cjihrig]

+1

[BethGriggs]

+1

[mhdawson]

+1

[MylesBorins]

Huge +1

[tniessen]

+1

[ChALkeR]

+1

[mhdawson]

@Trott I think I see 16 +1s. I think this issue constitutes the required vote so we could consider this concluded by Monday so that Richard can be a member by the next meeting. Make sense?

[Trott]

Obviously, I'm +1, but leaving this here to make it official.

[mhdawson]

Sounds like we are in agreement that we can formally confirm in the next TSC meeting. @richardlau welcome to the TSC :)

[Trott]

I've copied the TSC onboarding checklist at https://github.com/nodejs/TSC/blob/main/ONBOARDING.md#onboarding below. Let's leave this open until these are all done:

• Confirm that the new member has read, understands, and agrees to uphold the
  Code of Conduct.
• Add the new member to the @nodejs/tsc and @nodejs/security-tsc teams.
• Change the new member's role in the GitHub nodejs organization to Owner.
• Add them to the @nodejs-private org and with an Owner role.
• Add them to the @nodejs-private/security-tsc team.
• Add them to the @pkgjs org and with an Owner role.
• Add them to the @pkgjs/node-tsc team.
• Invite them to the HackerOne Node.js team.
• Add them to the tsc and crypto-export mailing lists.
• Update the @nodejs/node repository README to reflect membership in the TSC.
• Update https://github.com/nodejs/create-node-meeting-artifacts/blob/master/templates/invited_tsc and https://github.com/nodejs/create-node-meeting-artifacts/blob/master/templates/observers_tsc to reflect membership in the TSC.

[Trott]

• Add the new member to the @nodejs/tsc and @nodejs/security-tsc teams.

Aside: We should get rid of security-tsc and use tsc for both purposes.

[targos]

We should get rid of security-tsc and use tsc for both purposes.

security-tsc exists to be a child team of security

[Trott]

We should get rid of security-tsc and use tsc for both purposes.

security-tsc exists to be a child team of security

Oh, right, I had thought of that but then figured tsc could be a child team of security but...that makes no sense. Never mind (unless someone has a good solution). I guess the real thing to do here is find a way to automate they synchronizing of security-tsc with tsc but that's probably more work than it's worth.

[Trott]

I guess the real thing to do here is find a way to automate they synchronizing of security-tsc with tsc but that's probably more work than it's worth.

I suppose an easy win could be a weekly Action job that compares the two teams and opens an issue if they're different. It could also (if given the correct permissions) compare against teams in nodejs-private that are supposed to be synchronized with teams in nodejs.