EPIC Goal

The RHDH UI team is responsible for many plugins, and not all of them were written by that/our team.

This Epic is about closing a knowledge gap by actively taking ownership of these plugins.

Complete list of responsibilities

Why is this important?

We can not support, esp. under the GA label plugins if we didn't take the time to investigate once.

We also like to show upstream that we're available.

Acceptance Criteria

Onboard a plugins means that we know the basics of that plugin. The result should be documented, for example as techdocs in the rhdh team docs GitLab project

1. Source repo, issue tracker and PR trackers are known
2. Any other public documentation we should know?
3. Public communication channel? Discord? Any planning meetings?
4. Is there a Roadmap from the community or from us?
5. Investigate the Source code and overlay repo build
   1. How good do we know the feature?
   2. How good do we know the related code? How long would it take to fix an upstream issue if a customer raises a bug
   3. Are there dependencies? Like a backend
   4. How to setup / test it manually? Esp. in RHDH or rhdh-local
6. Support level is well known?
7. Overlay repo status? (Workspace exist? Codeowners includes our owners?)
8. Extensions plugin yaml (Exists? Does it need an update based on the learnings?)

Plugins that we should take care of in 1.8:

1. TBD – Priorize based on Support Level ??
2. First look into orchastrator plugin since it moves to RHDH and goes GA in 1.8? See RHDHPLAN-179 and RHIDP-6232
3. Deeper look into Kubernetes Frontend plugin because it goes from TP to GA in 1.8? See RHIDP-7914