• Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • 1.8.0
    • None
    • Scorecard plugin
    • None
    • Phase 1 Scorecard implementation backend plugin
    • M
    • False
    • Hide

      None

      Show
      None
    • False
    • RHIDP-8258Phase 1 Scorecard implementation (Developer Preview)
    • In Progress
    • RHIDP-8258 - Phase 1 Scorecard implementation (Developer Preview)
    • QE Needed, Docs Needed, TE Needed, Customer Facing, PX Needed
    • 10% To Do, 10% In Progress, 80% Done

      EPIC Goal

      Introduce a new backend plugin for configuring and managing KPIs from various sources.

      Background/Feature Origin

      This feature aims to empower platform engineers to configure and manage Key Performance Indicators (KPIs) and integrate Scorecard data from various sources within the Red Hat Developer Hub (RHDH) platform. This will provide developers with personalized and role-based access to crucial project metrics and performance insights. The initial version will release as a developer preview.

      Why is this important?

      User Scenarios

      • Platform engineers must be able to create and group KPIs, defining data sources and thresholds via YAML configuration.
      • The system must securely handle authentication with integrated services (starting with Jira and GitHub) using existing RHDH authentication mechanisms.
      • RBAC must be implemented to manage KPI access and display based on user roles.
      • KPIs and Scorecard data should be rendered on designated RHDH pages (e.g., homepage, entity overview).
      • The initial 1.8 goal is to display a single metric with basic threshold-based coloring.
      • The scorecard will initially be implemented without database persistence, calculating scores on the fly when an entity card is viewed.
      • The scorecard plugin will be built from scratch and integrate directly with Backstage.
      • The scorecard plugin will depend on the installation of relevant data source plugins (e.g., Jira, GitHub), but not have a hard dependency on any of them, as each customer environment will be unique.
      • Customization will initially be defined by platform engineers for developer personas.
      • Provide an empty state experience that is available by default, to enhance discoverability.

      Dependencies (internal and external)

      Frontend plugin team

      Acceptance Criteria

      Release Enablement/Demo - Provide necessary release enablement details
      and documents

      DEV - Upstream code and tests merged: <link to meaningful PR or GitHub
      Issue>

      DEV - Upstream documentation merged: <link to meaningful PR or GitHub
      Issue>

      DEV - Downstream build attached to advisory: <link to errata>

      QE - Test plans in Playwright: <link or reference to playwright>

      QE - Automated tests merged: <link or reference to automated tests>

      DOC - Downstream documentation merged: <link to meaningful PR>

              rh-ee-dzemanov Dominika Zemanovicova
              rh-ee-pknight Patrick Knight
              RHIDP - Plugins
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: