Feature Request: Integrate Lottery Factor Explorer

[TineoC]

Proposed Feature or Enhancement

From @kaslin suggestion here

Motivation

Understanding the "lotery factor" across the various subprojects and SIGs is critical for the long-term health and sustainability of Kubernetes.

Currently, it can be difficult for maintainers to get a birds-eye view of where their single points of failure are in terms of code contributions and reviews. By surfacing these metrics directly on k8s.dev, we can proactively identify at-risk components and focus our mentoring and onboarding efforts more effectively.

Additional Context

• Tool Repository: JetBrains-Research/bus-factor-explorer

/sig contribex

[k8s-ci-robot]

@TineoC: The label(s) sig/contribex cannot be applied, because the repository doesn't have them.

Details

In response to this:

Proposed Feature or Enhancement

Based on a great suggestion from @kaslin, I'd like to propose integrating the Bus Factor (or "Lottery Factor") Explorer into k8s.dev (or hosting it as a standalone tool run by SIG ContribEx).

Kaslin suggested a while ago that running a copy of this app for the Kubernetes project would be highly valuable. It would allow maintainers to easily visualize the areas they own that are at the highest risk if a key contributor were to leave the project, as well as identify areas that may already be quietly unmaintained without their knowledge.

Motivation

Understanding the "bus factor" across the various subprojects and SIGs is critical for the long-term health and sustainability of Kubernetes.

Currently, it can be difficult for maintainers to get a birds-eye view of where their single points of failure are in terms of code contributions and reviews. By surfacing these metrics directly on k8s.dev, we can proactively identify at-risk components and focus our mentoring and onboarding efforts more effectively.

Additional Context

• Tool Repository: JetBrains-Research/bus-factor-explorer
• This would likely require setting up a recurring job to process the Kubernetes org data and serving the resulting static site, or integrating the data into the existing k8s.dev Hugo site.

/sig contribex

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jberkus]

Any idea what the infra requirements for this are? Presumably netlify isn't going to run it for us.

[TineoC]

@jberkus We haven't discuss that, we're open for feedback. What do you think doing this in grafana and generating this data every week?

I built this demo locally

[TineoC]

[TineoC]

https://k8s.devstats.cncf.io/d/34/pr-workload-per-sig-table?orgId=1

[TineoC]

From slack https://kubernetes.slack.com/archives/C1TU9EB9S/p1774030010160699:

User Story: The Community Resilience Dashboard

Title: [Lottery Factor] Integrate Community Resilience Dashboard into k8s.dev

As a: Kubernetes SIG Chair, Subproject Owner, or Steering Committee Member

I want to: Access a Community Resilience Dashboard that maps individual maintainer concentration to organizational risk, specifically highlighting which SIGs and subprojects are dependent on "overloaded" maintainers.

So that: I can identify systemic "Single Points of Failure" and strategically direct mentorship, onboarding, and resources to the specific areas that pose the highest risk to project sustainability.

Acceptance Criteria

• SIG Risk Attribution: Rather than just listing overloaded individuals, the tool must visualize a "Risk by SIG" view. If a maintainer is identified as "overloaded," every SIG/subproject they support must be flagged as having a reduced "Lottery Factor."
• Robot/Bot Filtering: The calculation engine must explicitly exclude non-human contributors (e.g., k8s-ci-robot) from maintainer-like activity counts (PR comments, labeling) to prevent skewed resilience metrics.
• Cross-SIG Impact Analysis: The dashboard must identify "Bridge Maintainers"—individuals whose absence would simultaneously impact multiple SIGs—allowing Steering to prioritize cross-functional contributor growth.
• Resource Correlation: Areas identified as "High Risk" or "Low Resilience" must be programmatically linked to relevant onboarding materials, SIG Onboarding Guides, or a curated list of "Good First Issues."
• SIG-Level Filtering & Drill-Down: Users must be able to filter the global view by specific SIG (e.g., SIG Architecture, SIG ContribEx) to see a localized health report of their specific subprojects.
• Automated Data Provenance: The dashboard must refresh weekly via a Prow job or GitHub Action and display a "Last Updated" timestamp and a link to the data source (e.g., a specific GitHub crawler run).

[TineoC]