Feature Overview (aka. Goal Summary)

This feature aims to clarify the support statuses for key developer tools and plugins within Red Hat Developer Hub, both in the product documentation and directly within the in-product Extensions Catalog. By providing clear and accessible guidance, we will help users understand what level of support they can expect for RHDH tools and plugins.

There are two major things that we wish to clarify with this documentation:

• The support status of RHDH Tools and tooling (like RHDH Local, rhdh-cli, etc.)
• The change in the support status of some plugins as we move from wrappers (internal to the RHDH container image) to OCI plugins (external to the RHDH container image) 

Important Note: It is important to create this documentation in such a way as to not alarm or confuse customers. Overall, the level of support they enjoy has not changed. For example, community plugins previously market as TP for distribution purposes and moving to community supported status were always actively maintained by us in the community - this process has not changed (only the mechanism used to report issues changes and the customers right to timely responses). Some plugins will even increase their level of support as part of this move.

A full list of plugins and tools affected will be added to this feature once clarified (work is underway to do this led by rh-ee-mhild ).

User Story

As a developer using RHDH, I want to clearly understand what tools and plugins are officially supported by Red Hat so that I can confidently build my solutions.

Goals (aka. Expected User Outcomes)

• Notify: Alert user to the fact that some support statuses for some plugins are changing and explain why this change is happening (the move from wrappers to OCI images) and what the effect is on customers using those plugins.
• Empower developers to build confidently: Developers and platform engineers will have a reliable source of truth, both in the documentation and in-product, to confidently build their solutions on RHDH, knowing which parts of the ecosystem are officially supported by Red Hat. This reduces the risk of relying too heavily on unsupported components.

• Streamline support and sales conversations: By clearly defining support statuses upfront, we can reduce the number of customer inquiries related to product scope and supportability, allowing our support and sales teams to have more productive conversations.

• Align with our OCI-first strategy: The documentation and in-product experience will clearly reflect Red Hat's long-term strategy of moving toward dynamic, OCI-packaged plugins and will use official Red Hat support statuses (GA, TP, DP).

• Transparency: Clarification of the support statuses of these tools and plugins should offer greater transparency to customers about how and where their software is maintained.

Requirements (aka. Acceptance Criteria)

• Given a user is navigating the RHDH documentation, when they visit the new "Support Status" (working title) page on RHDH tools and tooling, then they should see a clear explanation of what each support status means (GA, TP, DP), the support status of each tool and information on who provides the support (e.g., Red Hat, Partner, Community).

• Given a user is navigating the RHDH documentation, when they visit the new "Support Status" (working title) page on RHDH plugins, then they should see a clear explanation of what each support status means (GA, TP, DP, Community Supported) as well as how to discover who provides the support (e.g., Red Hat, Partner, Community) and where to find their contact details.
• Given a user is browsing the Extensions Catalog in the RHDH UI, when they view a plugin, then the UI must clearly display its support status and the name of the organization that supports it (work done as part of RHDH 1.8).

• Given a user is reading about a core Red Hat feature in the documentation, when there are relevant community or unsupported tools, then the documentation should reference these tools with a clear disclaimer that they are not supported by Red Hat.

• Given a user is on the new documentation page, when they look for information on RHDH Local, rhdh-cli, and Dynamic Plugin Factory, then they should find their official Red Hat support statuses.

• Given a user navigates to the Release Notes for this release, when they read the Release Notes, then they will see a Release Note describing the addition of this new support page explaining that the support statuses for tools is being clarified and that some plugins have also had their support status clarified.

Customer Considerations

• This documentation is especially critical for our enterprise customers who are actively building custom solutions on RHDH and need clear, official guidance to plan their development and support strategy. This provides them with the clarity and confidence to invest in the platform.

• Clarifying these statuses will help our support and sales teams manage customer expectations and prevent confusion, particularly as we transition to a dynamic plugin model.

Documentation Considerations

• Create: A new, dedicated documentation page or section titled "Understanding RHDH Support Statuses and Plugins" should be created. This guide should serve as the single source of truth for all support-related questions.

• Update: The in-product Extensions Catalog should be updated to display the support status and organization for each listed plugin. This is a critical part of the user experience and needs to be documented for the team. (These changes were completed as part of RHDH 1.8 and further managed on an ongoing basis by rh-ee-mhild )

• Add: Where appropriate, add links within the documentation to external, community-maintained tools or projects, ensuring a clear disclaimer is present to manage support expectations.

Further reading:

There are changes to how plugins will be built and shipped, when we move to OCI images (see RHIDP-8211, RHIDP-6016, RHDHPLAN-225). Customers will need to understand the changes.

Who is your target persona?

<Role>

What stage of the user journey are you targeting?

<User journey>

Why is this content important?

<Justification>

What is the main user goal aka job to be done?

As a <role>, I want to <goal>

What high level steps does the user need to take to accomplish the goal?

1. <User steps to accomplish goal>
   

What pain points are the user likely to encounter when accomplishing this goal?

<Pain points>

Links to existing content

• <Add link to content>
  

People:

• SME: <SME>
  
• QE: <QE>
  

Release Note: Yes/No

Documentation Outline

• <Documentation outline>