assign-findings-owners

name	assign-findings-owners
description	Use when the user asks to determine, assign, or verify owners for one or more result directories in progress-tracker/processed-results/. Identifies two lead developers per findings package using owners.csv mappings, org repo team structures, OpenShift CI OWNERS files, LDAP employee verification, and git commit email resolution.
user-invocable	true

Assign Findings Owners

Determine two Red Hat lead developer owners for each result directory in progress-tracker/processed-results/. The owners are the primary contacts who will receive the security findings and delegate remediation to their sub-teams.

When to Use

• User asks to "assign owners" to findings packages
• User asks "who owns" a result directory
• User asks to "determine owners" or "find owners" for processed results
• User asks to "update routed-results" with owner assignments

Inputs

$ARGUMENTS is one or more result directory names (with or without the -findings suffix), or all to process every directory under processed-results/.

Examples:

/assign-findings-owners openshift-pipelines
/assign-findings-owners acm-mce-gatekeeper-globalhub-volsync openshift-virtualization
/assign-findings-owners all

Output

For each result directory, produce a table:

| # | Name | GitHub | Red Hat Email | Rationale |
|---|------|--------|---------------|-----------|
| 1 | Full Name | github-username | [e-mail] | Why this person — role, repo coverage, org position |
| 2 | Full Name | github-username | [e-mail] | Why this person — role, repo coverage, org position |

If the user confirms the assignments, append them to progress-tracker/routed-results.md.

---

Procedure

Step 1 — Identify the Result Directory

Resolve each argument to a directory under progress-tracker/processed-results/:

RESULTS_BASE="progress-tracker/processed-results"

If the argument doesn't end in -findings, append it. Verify the directory exists. List its sub-directories to understand the scope — multi-product packages (like acm-mce-gatekeeper-globalhub-volsync-findings/) have product sub-directories, while single-operator packages have component sub-directories.

Step 2 — Gather Ownership Data from owners.csv

The hybrid-platforms-inputs/ repository contains owners.csv files that map repositories to teams and individual owners. Locate the relevant ones:

1. Multi-product packages — The directory name indicates which products are included. Map product names to operator-catalog directories:

   Product keyword	owners.csv path
   acm, rhacm	operator-catalog/advanced-cluster-management/owners.csv
   mce	operator-catalog/multicluster-engine/owners.csv
   gatekeeper	operator-catalog/gatekeeper-operator-product/owners.csv
   globalhub	operator-catalog/multicluster-global-hub-operator-rh/owners.csv
   volsync	operator-catalog/volsync-product/owners.csv
   virtualization, kubevirt	operator-catalog/kubevirt-hyperconverged/owners.csv
   pipelines, tekton	operator-catalog/openshift-pipelines-operator-rh/owners.csv
   gitops, argocd	operator-catalog/openshift-gitops-operator/owners.csv
   servicemesh	operator-catalog/servicemeshoperator/owners.csv
   logging	operator-catalog/cluster-logging/owners.csv

2. Single-operator packages — The directory name (minus -findings) is usually the operator name. Search for a matching directory:

   ls hybrid-platforms-inputs/operator-catalog/ | grep -i "<operator-name>"
   

3. If no owners.csv is found via operator-catalog, check openshift/owners.csv and services/*/owners.csv.

Parse each owners.csv — the format is:

Repository,URL,Owner Team,Manager,Individual Owners,Ownership Source,Operator Versions

Extract and tally:

• Individual Owners column — count how many repos each person appears on
• Owner Team column — identify the dominant team(s)
• Manager column — note the managers (for delegation chain, not as owners)
• Ownership Source — prefer hybrid-platforms-org entries (highest fidelity)

Filter out shared-infrastructure contributors who appear in owners.csv only because shared dependencies (kube-rbac-proxy, oauth-proxy, prometheus) are included in every operator bundle. These are not domain-specific owners:

stlaz, s-urbaniak, ibihim, root-approvers, sdk-admins,
control-plane-approvers, openshift-storage-maintainers,
openshift-knative, knative-client-approvers, capi-admins,
sdk-approvers, edge-enablement-approvers

Also filter non-person entries: openstack-k8s-operators, rhdh-cope, rhdh-security, istio-testing, renovate-bot, team slugs, etc.

Filter out shared-dependency repositories before tallying individual owners. Many operator bundles include images built from shared upstream repos whose owners are unrelated to the operator's product team. When counting repo ownership frequency (above), skip rows whose Repository or URL matches any of these shared-dependency repos:

openshift/prometheus
openshift/prometheus-operator
openshift/prometheus-alertmanager
openshift/kube-rbac-proxy
openshift/oauth-proxy
openshift/ocp-release-operator-sdk
openshift/kube-state-metrics
rh-openjdk/redhat-openjdk-containers

If after filtering the only remaining individual owners come from these shared repos, fall back to the operator's own CI OWNERS file (Step 3), org repo team structure (Step 4), or GitHub contributors API (Step 5f) to find the actual product-team owners.

Why this matters: In prior runs, Simon Pasquier was assigned as owner on 8 unrelated folders (Skupper, Fuse Online, ODF, RHODS, OpenStack) because he owns openshift/prometheus which is bundled into all of them. The correct owners are the product-team leads for each operator.

Step 3 — Cross-Reference with OpenShift CI OWNERS Files

The openshift/release repository (https://github.com/openshift/release) contains OWNERS files for every component that uses OpenShift CI. These are high-quality signals for downstream Red Hat ownership — they list the approvers and reviewers who are authorized to merge CI configuration changes for each component.

3a. Map Repos to CI Paths

Extract repository URLs from the findings reports themselves. Each audit report under processed-results/<dir>/ contains a Repository metadata field (e.g., | **Repository** | https://github.com/ComplianceAsCode/compliance-operator |). Parse these to get the correct <github-org>/<repo-name> — do NOT assume all repos live under the openshift/ GitHub org. Many operators use upstream orgs (e.g., ComplianceAsCode, kubev2v, openshift-pipelines, stolostron).

For each repository URL extracted from findings (or from owners.csv), check for an OWNERS file at:

https://github.com/openshift/release/tree/master/ci-operator/config/<github-org>/<repo-name>/OWNERS

For upstream repos that also have downstream forks, additionally check:

ci-operator/config/openshift/<repo-name>/OWNERS

If the workspace has a local clone of openshift/release, use it directly:

cat release/ci-operator/config/<github-org>/<repo-name>/OWNERS

3b. Parse OWNERS Files

OWNERS files are YAML with this structure:

approvers:
  - username1
  - username2
reviewers:
  - username3
  - username4

Collect approvers from all matching OWNERS files and tally frequency. Approvers are preferred over reviewers — they have merge authority.

3c. Filter Results

The top-level ci-operator/config/OWNERS lists generic CI platform approvers (dptp team). Filter these out — they are CI infrastructure, not component owners:

derekwaynecarr, eparis, jwforres, bparees, imcleod, jupierce,
knobunc, mrunalp, sdodson, shawn-hurley, dptp

Also discard matches from unrelated repos that happen to share a substring (e.g. openshift-pipelines/operator matching the word operator in an unrelated search). Only use OWNERS from repos that are actually part of the operator being analyzed.

3d. When CI OWNERS Are Especially Valuable

• Operators with no owners.csv — CI OWNERS may be the only source
• owners.csv lists only team slugs (e.g. control-plane-approvers) — CI OWNERS lists actual individuals
• Upstream-only contributors — CI OWNERS for OpenShift downstream forks typically list Red Hat employees, not upstream community members
• Cross-validation — a person appearing in both owners.csv AND CI OWNERS is a very strong candidate

Step 4 — Cross-Reference with Org Repo

The org/config/structures/ directory contains YAML files defining team structures, roles, and repo ownership. Search for teams related to the products in this findings package:

grep -rl "<product-keyword>" org/config/structures/hybrid_platforms/

Read matching YAML files. Each team file follows this structure:

name: Team Name
group:
  parent: c/structures/...
  roles:
    - people:
        ids:
          - kerberos_id
      types:
        - manager          # Team manager
    - people:
        ids:
          - kerberos_id
      types:
        - staff_engineer   # Senior technical lead
    - people:
        ids:
          - kerberos_id
      types:
        - team_lead        # Day-to-day technical lead
    - people:
        ids:
          - kerberos_id
      types:
        - architect        # Technical architect
  repos:
    - repo: https://github.com/org/repo
      description: ...

Priority of org roles for owner selection (highest to lowest):

1. staff_engineer — Senior technical authority, ideal owner
2. team_lead — Day-to-day technical lead
3. architect — Technical architect
4. advisory — Advisory/senior contributor (often senior principal engineers)
5. manager — Engineering manager (good for delegation chain, less ideal as findings owner since they're not hands-on)

Cross-reference the org repo data with owners.csv and CI OWNERS:

• A person appearing in all three sources is an extremely strong candidate.
• A person who appears as staff_engineer in org AND as top individual owner in owners.csv is a strong candidate.
• A Kerberos ID in the org repo may differ from the GitHub username — you'll need to resolve this in Step 5.

Step 5 — Verify Identities and Resolve Emails

For each candidate owner, verify they are a current Red Hat employee and resolve their full identity (name, GitHub username, Red Hat email). Use these sources in order of reliability:

5a. Git Commit Email Resolution (Most Reliable)

The most reliable way to map GitHub username → Red Hat email is to fetch a .patch of their recent commit and read the From: / Signed-off-by: lines:

https://api.github.com/repos/<org>/<repo>/commits?author=<username>&per_page=1

Then fetch the patch:

https://github.com/<org>/<repo>/commit/<sha>.patch

Look for lines matching:

From: Full Name <[e-mail]>
Signed-off-by: Full Name <[e-mail]>

Try multiple repos — a contributor may use a personal email in the upstream project but their @redhat.com email in OpenShift downstream forks. Search across these orgs in order:

1. openshift (downstream forks — most likely to have RH emails)
2. stolostron, redhat-developer, red-hat-storage (RH-owned orgs)
3. stackrox, quay, kubev2v, netobserv (RH product orgs)
4. The upstream project org (least likely to have RH emails)

5b. Verify via Corporate LDAP (Blocking)

Every candidate owner must be verified as an active Red Hat employee via corporate LDAP before they can be selected. This is a blocking check — a candidate who cannot be verified must be replaced.

Running the Verification Script

The repository includes scripts/validate_employee.py in the scripts/ directory. It queries ldap.corp.redhat.com directly and requires VPN access.

python scripts/validate_employee.py <kerberos_id> [<kerberos_id> ...]

The script requires the ldap3 Python package (listed in requirements.txt at the repo root). Before first use, verify it is installed:

python -c "import ldap3" 2>/dev/null || pip install -r requirements.txt

Pass --debug to print all LDAP attributes for each entry (useful for discovering additional fields like job title or manager).

Interpreting Output

Script output	Verdict
<uid> (Full Name): active employee	PASS — current Red Hat employee
<uid> (Full Name): terminated (rhatTermDate=<date>)	DISQUALIFY — former employee
<uid>: NOT found	DISQUALIFY — not in LDAP (may be a GitHub username, not a Kerberos ID — resolve via org repo or git commit email)
<uid>: skipped (CN region)	NOTE — temporarily excluded (CN region filter)

The script exits with code 0 when all looked-up users are active, or code 1 when any user is not found or terminated.

Resolution Chain

1. If a Kerberos ID is known (from org repo team YAML ids: fields or the local part of a @redhat.com git commit signature), run the script directly:

   python scripts/validate_employee.py <kerberos_id>
   

   • active employee → PASS
   • terminated or NOT found → disqualify

2. If only a GitHub username is known, resolve to a Kerberos ID. Do NOT assume the GitHub username is the Kerberos ID — they frequently differ (e.g. vladikr → vromanso, fabiand → fdeutsch, dhaiducek → dhaiduce). Resolve in this order:

   • Org repo (preferred): search the org repo team YAML files (Step 4) for a person whose role matches the candidate. The ids: fields in org repo contain Kerberos IDs. Cross-reference by matching the team, repos, and role to identify which Kerberos ID corresponds to the GitHub username.
   • Git commit email: fetch a .patch of a recent commit by the GitHub user (Step 5a) and read the From: line for <user>@redhat.com — the local part before @redhat.com is typically the Kerberos ID.
   • Known mappings table: check the Kerberos ↔ GitHub Username Mapping table at the end of this document for previously resolved mappings.
   • Run the script with the resolved Kerberos ID to confirm active employment.
   • If no Kerberos ID can be resolved, disqualify the candidate and select the next-best candidate from Steps 2–4.

Batch Verification

Pass all candidate Kerberos IDs in a single invocation for efficiency. Use resolved Kerberos IDs, not GitHub usernames:

python scripts/validate_employee.py dhaiduce gparvin vromanso fdeutsch

Each user's status is printed on its own line.

Important: Never select an owner who cannot be verified as a current Red Hat employee. If LDAP verification fails or is ambiguous for a candidate, replace them with the next-highest-ranked candidate and re-run verification on the replacement. Note the disqualification reason in the rationale (e.g., "replaced rmohr — no longer at Red Hat per LDAP", "replaced periklis — not found in LDAP, now at Grafana Labs").

Fallback When LDAP Is Inaccessible

If LDAP is inaccessible (not connected to VPN), fall back to git commit email resolution (Step 5a) combined with GitHub profile employer check (Step 5d) — but flag to the user that LDAP verification was skipped and should be completed before finalizing assignments. Assignments made without LDAP verification should be marked as provisional in the results table.

Provisional assignments MUST NOT be recorded to routed-results.md (Step 8). When presenting provisional results in Step 7, append "(provisional — LDAP verification pending)" to each rationale cell. Before the user can confirm and finalize, re-run scripts/validate_employee.py with VPN access to promote or disqualify each candidate.

5c. Maven pom.xml and Project Metadata

Many Java/middleware projects list developer emails in pom.xml:

<developer>
    <id>username</id>
    <name>Full Name</name>
    <email>[e-mail]</email>
    <organization>Red Hat</organization>
</developer>

Search via Sourcegraph or GitHub code search:

<email>[e-mail]</email> repo:<org>/<project>

This is especially useful for upstream middleware projects (Keycloak, Infinispan, Strimzi, Apicurio, Camel, JBoss EAP) where contributors often use personal emails in git commits but their RH emails in pom.xml.

5d. GitHub Profile Check

Check the GitHub profile for current employer:

https://github.com/<username>

Look at the company field and org memberships. Critical: People leave Red Hat — if the profile shows a different employer (e.g. @googlers, Cloudera, Vercel, IBM), that person is not a valid owner. Find their replacement by:

1. Checking the CI OWNERS file for the downstream fork in openshift/release
2. Finding the next most active Red Hat contributor via the GitHub contributors API: https://api.github.com/repos/<org>/<repo>/contributors?per_page=20
3. Checking the upstream project's MAINTAINERS.md or OWNERS file for current Red Hat-affiliated maintainers
4. Looking in the org repo team YAML for the replacement team lead

5e. Conference/Blog Verification

For senior engineers, KubeCon/DevConf speaker profiles and Red Hat blog author pages often confirm current employment and title:

https://www.redhat.com/en/authors/<name>

5f. GitHub Contributors API (Fallback for Finding RH People)

When owners.csv and CI OWNERS both yield upstream-only contributors, search the repo's contributor list for Red Hat employees directly:

https://api.github.com/repos/<org>/<repo>/contributors?per_page=20

For each top contributor, fetch a recent commit patch and check for @redhat.com in From: or Signed-off-by:. The first contributor with a confirmed @redhat.com email is the best replacement.

Important: Red Hat Kerberos IDs (used in org repo) often differ from GitHub usernames. Examples discovered during validation:

• vromanso (Kerberos) = vladikr (GitHub) — Vladik Romanovsky
• fdeutsch (Kerberos) = fabiand (GitHub) — Fabian Deutsch
• dhaiduce (Kerberos) = dhaiducek (GitHub) — Dale Haiducek
• mkrutov (GitHub) has a second account rhmkrutov with RH email

Step 6 — Select Two Owners

Apply these selection criteria, in priority order:

1. Breadth of coverage — The two owners together should cover the maximum number of sub-directories/components in the findings package. For multi-product packages, ideally one owner per major product area.

2. Technical seniority — Prefer staff_engineer > team_lead > architect > advisory > CI approver > frequent individual contributor > manager.

3. Repo ownership frequency — From owners.csv, the person listed as individual owner on the most repos has the broadest context.

4. CI approver status — People listed as approvers in openshift/release CI config have merge authority for the downstream build — strong signal of hands-on ownership.

5. Current Red Hat employee — Verified via Step 5. Non-employees are disqualified.

6. Delegation capability — The selected owners should be in a position to delegate to sub-team leads. Note the delegation chain in the rationale.

For multi-product packages with distinct sub-areas (e.g. openshift-virtualization-findings has kubevirt-hyperconverged/ and mtv-operator/): select one owner per sub-area rather than two from the same sub-area.

For single-operator packages: select the two most prolific individual owners from owners.csv, cross-referenced with CI OWNERS and org repo roles.

When top owners.csv contributors are upstream-only: replace them with the top Red Hat contributors from CI OWNERS or the GitHub contributors API. Use the person who appears most frequently across the operator's repos.

Step 7 — Present Results

For each result directory, present a summary table:

### `<directory-name>`

| # | Name | GitHub | Red Hat Email | Rationale |
|---|------|--------|---------------|-----------|
| 1 | **Full Name** | `github-username` | `[e-mail]` | Role, repo coverage, delegation path |
| 2 | **Full Name** | `github-username` | `[e-mail]` | Role, repo coverage, delegation path |

Include a brief note on who the owners can delegate to for specific sub-products or components.

Step 8 — Record Assignments (After User Confirmation)

Once the user confirms the assignments, append entries to progress-tracker/routed-results.md:

| <next-number> | [<directory-name>](processed-results/<directory-name>/) | [e-mail], [e-mail] | <today's date YYYY-MM-DD> |

Use the existing format in routed-results.md — the table has columns: #, Result Package, Routed To, Date.

---

Data Source Reference

Source 1: owners.csv (Local)

hybrid-platforms-inputs/
├── openshift/owners.csv                          # OpenShift payload repos
├── operator-catalog/<operator>/owners.csv        # Per-operator ownership
└── services/<service>/owners.csv                 # Managed service repos

Columns: Repository,URL,Owner Team,Manager,Individual Owners,Ownership Source,Operator Versions

Best for: initial candidate identification, team/manager context, breadth analysis.

Source 2: OpenShift CI OWNERS (Remote)

https://github.com/openshift/release/tree/master/ci-operator/config/
├── <github-org>/
│   └── <repo-name>/
│       └── OWNERS          # approvers + reviewers for this component's CI

Repository: https://github.com/openshift/release

Clone locally for batch processing:

git clone --depth 1 --filter=blob:none --sparse https://github.com/openshift/release.git /tmp/release
cd /tmp/release && git sparse-checkout set ci-operator/config

Or fetch individual OWNERS files via raw URL:

https://raw.githubusercontent.com/openshift/release/master/ci-operator/config/<org>/<repo>/OWNERS

Best for: finding Red Hat downstream owners when owners.csv only has upstream contributors, resolving team slugs to individuals, finding owners for operators without an owners.csv.

Coverage: ~500 repos under ci-operator/config/openshift/, plus repos from ~100 other orgs (stolostron, stackrox, quay, kubev2v, medik8s, etc.). Does NOT cover middleware products that manage CI outside OpenShift CI (AMQ, Keycloak, Infinispan, Apicurio, JBoss EAP).

Source 3: Org Repo Team Structure (Local)

org/config/structures/hybrid_platforms/
├── fleet/teams/                  # ACM, MCE, Gatekeeper, GlobalHub, VolSync
├── vme/teams/                    # OpenShift Virtualization, MTV, Forklift
├── affiliated/teams/             # Pipelines, GitOps, Logging, etc.
├── mpex/teams/                   # Observability, Analytics
├── openshift/teams/              # Core OpenShift platform teams
└── ...

Best for: role hierarchy (staff_engineer, team_lead, etc.), manager chain, team → Jira project mapping, Kerberos IDs.

Source 4: Corporate LDAP (Remote, VPN Required)

Queried via scripts/validate_employee.py in the scripts/ directory. Requires VPN access to reach ldap.corp.redhat.com.

python scripts/validate_employee.py <kerberos_id> [<kerberos_id> ...]

Key LDAP attributes (visible with --debug): uid, c (country), rhatTermDate (separation date if terminated), employeeType, mail.

Best for: blocking verification of active employment. Confirms whether a Kerberos ID corresponds to an active employee, terminated employee, or unknown user.

Source 5: Git Commit Patches (Remote)

https://github.com/<org>/<repo>/commit/<sha>.patch

Best for: resolving GitHub username → @redhat.com email via From: / Signed-off-by: lines. Most reliable automated method.

Source 6: Maven/Project Metadata (Remote)

Search pom.xml files in upstream projects for <email>[e-mail]</email>:

https://raw.githubusercontent.com/<org>/<repo>/main/pom.xml

Best for: Java/middleware projects (Keycloak, Infinispan, Strimzi, Apicurio, Camel, JBoss EAP) where developers use personal emails in commits but their RH emails in project metadata.

Source 7: GitHub Contributors API (Remote)

https://api.github.com/repos/<org>/<repo>/contributors?per_page=20

Best for: finding replacement owners when original candidates are no longer at Red Hat. Iterate through top contributors and check each for @redhat.com commit emails.

---

Kerberos ↔ GitHub Username Mapping

There is no single lookup table. You must resolve mappings case-by-case using git commit patches (Step 5a). Known mappings discovered during prior runs:

Kerberos ID	GitHub Username	Name
vromanso	vladikr	Vladik Romanovsky
fdeutsch	fabiand	Fabian Deutsch
dhaiduce	dhaiducek	Dale Haiducek
vdemeest	vdemeester	Vincent Demeester
sashture	savitaashture	Savita Ashture
gparvin	gparvin	Gus Parvin
dkenigsb	dkenigsberg	Dan Kenigsberg
jortel	jortel	Jeff Ortel
ahadas	ahadas	Arik Hadas
mkrutov	mkrutov / rhmkrutov	Mikhail Krutov
mschuppert	stuggi	Martin Schuppert
jwendell	jwendell	Jonh Wendell
bfitzpat	bfitzpat	Brian Fitzpatrick

Add new mappings to this table as you discover them.

---

Validated Assignments

These assignments have been verified and confirmed. Use them as reference for consistency and to avoid re-doing work:

acm-mce-gatekeeper-globalhub-volsync-findings

#	Name	GitHub	Red Hat Email	Rationale
1	Dale Haiducek	dhaiducek	[e-mail]	Most prolific individual owner across 20+ repos spanning RHACM GRC/policy, MCE foundation, and Gatekeeper. Lead approver on governance-policy repos.
2	Gus Parvin	gparvin	[e-mail]	Staff Engineer for Management Workloads team. Co-owner with Haiducek on all GRC/policy repos + Gatekeeper. Org repo designates him as staff_engineer.

Delegation: dmetzger (VolSync/Apps), tsze/nirrozenbaum (GlobalHub).

openshift-virtualization-findings

#	Name	GitHub	Red Hat Email	Rationale
1	Vladik Romanovsky	vladikr	[e-mail]	Senior Principal SWE, current KubeVirt maintainer (Architecture & Enhancements). Advisory role in org repo for OpenShift Virt team group. Covers kubevirt-hyperconverged/.
2	Arik Hadas	ahadas	[e-mail]	Lead developer and CODEOWNER of forklift. Covers mtv-operator/.

Note: rmohr (Roman Mohr) from owners.csv has left Red Hat for Google.

openshift-pipelines-findings

#	Name	GitHub	Red Hat Email	Rationale
1	Vincent Demeester	vdemeester	[e-mail]	Senior Principal SWE, Tekton/OpenShift Pipelines maintainer. Individual owner on 14 of 27 repos.
2	Savita Ashture	savitaashture	[e-mail]	Co-owner on 10+ repos including pipeline, chains, CLI, triggers, and hub.

Delegation: chmouel (caches/opc), pramodbindal (operator/pruner).

---

Resolution Strategy by Product Type

Different product areas require different source priorities:

Product Type	Primary Source	Secondary	Tertiary	Notes
Core OpenShift	CI OWNERS	owners.csv	Org repo	Strong CI OWNERS coverage
ACM / MCE / Fleet	owners.csv	Org repo	CI OWNERS	Good owners.csv + org coverage
OpenShift Virt / MTV	owners.csv	Org repo	CI OWNERS	Check KubeVirt MAINTAINERS.md
OpenStack operators	CI OWNERS	owners.csv (stuggi)	Contributors API	Single-team; use cross-repo contributor tally
Middleware (AMQ, Keycloak, EAP)	pom.xml	LDAP	owners.csv	CI outside openshift/release; use Maven metadata
Apicurio / Service Registry	pom.xml	LDAP	owners.csv	Same as middleware
Quay / ACS	CI OWNERS	owners.csv	Contributors API	StackRox/Quay CI configs exist
Serverless / Pipelines	owners.csv	CI OWNERS	Org repo	Strong owners.csv coverage
Sigstore / Trustification	CI OWNERS	Contributors API	LDAP	Newer projects; CI OWNERS is best
MedIK8s / Node Health	CI OWNERS	owners.csv	Org repo	Good CI OWNERS coverage

---

Gotchas

• People leave Red Hat. Always verify current employment via GitHub profile company field and recent commit activity. Known departures from prior runs:

  • rmohr (Roman Mohr) — left for Google (KubeVirt)
  • scholzj (Jakub Scholz) — left for Cloudera (Strimzi)
  • blake-mealey — left for Vercel (Apicurio)
  • erh / dwight — MongoDB founders, never were at Red Hat (exploit-iq owners.csv listed them from the upstream MongoDB dependency, not the operator)

• Kerberos IDs ≠ GitHub usernames. The org repo uses Kerberos IDs, while owners.csv and CI OWNERS use GitHub usernames. These frequently differ — never pass a GitHub username to scripts/validate_employee.py. Resolve Kerberos IDs from the org repo team YAML ids: fields first (most reliable), or from @redhat.com git commit signatures. A NOT found result from the LDAP script usually means you passed a GitHub username instead of a Kerberos ID, not that the person doesn't exist.

• Red Hat email ≠ Kerberos + @redhat.com. Usually it is, but not always (e.g. [e-mail] not [e-mail], [e-mail] not [e-mail]). Always verify via git commit patches or LDAP (scripts/validate_employee.py).

• LDAP requires VPN. If LDAP is inaccessible, git commit signatures are the most reliable fallback for email verification, followed by pom.xml metadata for middleware projects.

• owners.csv may list team names, not individuals. Entries like openshift-storage-maintainers or root-approvers are GitHub team slugs, not people. Resolve via CI OWNERS, the org repo, or GitHub team membership.

• CI OWNERS can match wrong repos. Searching ci-operator/config/ by operator name may hit unrelated repos (e.g. searching "operator" matches openshift-pipelines/operator). Always verify the matched OWNERS file is from a repo that actually belongs to the operator being analyzed.

• Shared-dependency owners ≠ product owners. openshift/prometheus, openshift/oauth-proxy, openshift/kube-rbac-proxy, and similar repos are bundled into dozens of operator images. Their owners (e.g. simonpasquier, slashpai for prometheus; ibihim for oauth-proxy) appear in every operator's owners.csv but are not product-team owners. Always filter these repos out before tallying individual owners (see Step 2). If the top candidates all come from shared dependencies, the operator probably has no product-specific owners.csv entries — use CI OWNERS, org repo teams, or the GitHub contributors API instead.

• Multi-product packages span multiple org teams. The two selected owners won't be experts on every sub-product — that's expected. They should be senior enough to delegate effectively.

• Upstream-only contributors. People listed in owners.csv via github-org-mapping+OWNERS-file or manual-mapping+top-contributors may be upstream community contributors, not Red Hat employees. Always verify affiliation. When an upstream contributor has no @redhat.com email, check CI OWNERS for the downstream fork in openshift/release — this usually lists Red Hat engineers.

• IBM / Red Hat overlap. Some contributors show "IBM" as employer on GitHub due to IBM's Red Hat acquisition. If their email is @redhat.com in git commits, they are valid Red Hat owners regardless of what GitHub profile says.