tetragon: create new specialized review teams

[mtardy]

Also remove inactive reviewers. Add a very minimal set of person in those teams, the idea is to extend by doing PR later and commenting here.

[joestringer]

cc @cilium/tetragon-reviewers just because it looks like GitHub is auto-removing that review request when it's assigned to the PR, but you folks would know best on this.

FYI for a similar proposal for cilium/cilium, we would typically link to a corresponding draft PR on the c/c repo that updates the codeowners. This can be a useful reference during review.

Concretely from a pure process perspective, these steps should occur in this order:

1. This PR would need to be generally approved by relevant members and merged by an org Committer
2. Manual team creation + sync into the underlying configuration in https://github.com/cilium/team-management. I'm happy to help with this once the PR is merged. Better not to do this before (1), in case another change goes through the repo in the mean time; org reconciliation workflows can overwrite manually applied changes. This repo is intended as the source of truth.
3. You would need to make an additional PR to cilium/tetragon repository (and/or any other relevant repositories) to update the codeowners files to use the new teams. By doing this after (2), GitHub will be able to successfully lint/scan the CODEOWNERS file, ensure it is valid and will be effective.

In future any updates to these teams can skip steps (2) and (3). After merge, updates to memberships of existing teams go through a manual human gate triggered via notification on #sig-community-bots. This part is a formality based on decisions made in public in this repository; this step is a precautionary security measure as a check on the automation.

[joestringer]

Just as a heads up for expectations around these:

We implement a similar pattern for CODEOWNERS for teams used by cilium/cilium. The idea we have for this is that each team is responsible for review & quality in the target area, and they should have the most context about any potential changes in the team membership, whether adding or removing people. Ultimately though for cilium/cilium the decision is up to the (Cilium) Committer group, and all PRs to membership in this repository are expected to have two approvals from (Cilium) Committers. Only the (Org) committers can merge PRs into this repository.

For ebpf-go library the owners are managed slightly differently, it's just the core maintainer group that approves all changes to all teams for that subproject.

[mtardy]

The idea we have for this is that each team is responsible for review & quality in the target area, and they should have the most context about any potential changes in the team membership, whether adding or removing people. Ultimately though for cilium/cilium the decision is up to the (Cilium) Committer group, and all PRs to membership in this repository are expected to have two approvals from (Cilium) Committers. Only the (Org) committers can merge PRs into this repository.

This seems ideal, thanks for more info on this :)

[kevsecurity]

Can add me here.