Skip to content

[Discuss] Proposal for a Kubeflow Contributor Recognition Platform (badges.kubeflow.org) #960

Description

@PR3MM

Hi everyone! 👋

My team and I have been brainstorming ways to help improve contributor retention and recognize the amazing work happening across the Kubeflow ecosystem.

Currently, Kubeflow contributors lack verifiable recognition beyond their GitHub activity graphs. This makes it especially hard to highlight crucial non-code contributions like authoring documentation, triaging issues, and organizing community events.

Inspired by systems like [Fedora Badges], we would love to propose (and volunteer to build) a native digital badging platform for the community: badges.kubeflow.org.

The High-Level Vision

  • A Standalone Community Hub: A public-facing Next.js frontend where contributors can log in via GitHub OAuth to view their "backpack" of earned badges.
  • Open Badges 3.0 Standard: All badges would be cryptographically minted using the open-source Open Badges specification, allowing contributors to easily export their Kubeflow achievements to LinkedIn and digital wallets.
  • Automated & Manual Issuance: A FastAPI backend that listens to kubeflow GitHub Webhooks to automatically award code-based badges (e.g., "First PR Merged"), while allowing WG leads to award manual badges for things like "Release Manager" or "Community Hero."

The Tech Stack (Self-Hosted & Open Source)

We want to avoid expensive, proprietary SaaS lock-in. We are proposing a lightweight, cloud-native stack that can be hosted on standard community infrastructure:

  • Frontend: Next.js / React
  • Backend: Python (FastAPI)
  • Engine: Open-source Open Badges issuer (e.g., Badgr Server core)
  • Storage: PostgreSQL (for metadata) and MinIO/S3 (for hosting the baked PNG/SVG images)

Next Steps & Feedback

Before we commit to drafting a formal Kubeflow Enhancement Proposal (KEP) with the full architecture and security models, we wanted to socialize the idea here to see if this aligns with the community's goals.

  • Does the community feel this would be a valuable addition to our ecosystem?
  • If we move forward, would anyone from wg-community or the Steering Committee be open to sponsoring the KEP?

My team is highly motivated and ready to volunteer for the implementation work if the community agrees on this direction. Let us know your thoughts!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions