Find some way of indicating commercial support options

[holly-cummins]

This will be more important as we get more commercially supported extensions coming in the ecosystem, both from cloud providers and other product providers.

[maxandersen]

whats the context?

we have the notion of "*-support" in the metadata that can is being used to capture red hat supported extensions. idea was that others can do the same in their extension and/or platform.

[holly-cummins]

There's two parts to this. One is what we put in the metadata, and the other is how we render it in the UI.

For the metadata, it sounds like *-support is our preferred solution, and we just need to do the work to document it on https://quarkus.io/version/main/guides/extension-metadata#quarkus-extension-yaml.

For the UI, we need to think about whether we want to display it on the cards or just the details page, whether we want a filter for it, whether we want to have links to extension-specific pricing pages or other extended data, and so on. Nothing hard, it just needs design work and implementation.

[holly-cummins]

We probably also want to capture sponsoring organisations and/or ones who are main maintainers.

EDIT: That's covered in #18

[edburns]

For example, Microsoft is developing and maintaining https://github.com/quarkiverse/quarkus-azure-services . How can we get the MS logo big and clear on there? Also where to get commercial support for the thing?

[maxandersen]

@edburns extensions can provide their logo using icon-url property as documented in https://quarkus.io/version/main/guides/extension-metadata#quarkus-extension-yaml. That would in this case be the azure logo I assume?

With respect to more structured info we can definitely explore options; but a low key simple way is that we simply embed into the extensions.io page the readme from the associated repo. @holly-cummins wdyt?

[holly-cummins]

With respect to more structured info we can definitely explore options; but a low key simple way is that we simply embed into the extensions.io page the readme from the associated repo. @holly-cummins wdyt?

@maxandersen I keep going back and forth on embedding the readme into the extensions page. At one point I was convinced it was the right thing to do, and then I changed my mind. One problem is that the audience for quarkus.io/extensions and a GitHub readme is different. Information about how to compile an extension doesn't belong on the extensions catalog, but it's totally appropriate on a readme. On the other hand, it would clearly be nice to have some lightweight mechanism for including free-form text on an extension's page... and having to write the same things down two or three times for all three places would just be annoying.

One option is to inline part of the documentation into the extensions page ... or there might even be a maximally-DRY option where some content is shared to the extensions page, the docs, and the readme, either by reading the adoc and then doing pushes to the readme (like all-contributors does), or by parsing the readme and inlining it in the adoc and extensions page. We'd perhaps surround the common content with a marker like #common or #docs or something.

I also thought it would be nice to have configuration options included in all three places.

But I think that's a bit bigger than the the structured option I was thinking of here, so I'll raise another WI to track the question (#251).

[maxandersen]

What users put in readme depends on where it's used. Vscode marketplace embeds it. So does nodejs. Neither of those jt makes much sense to have compile info either and they adjust.

[holly-cummins]

Thinking more about *-support, @maxandersen, do I understand correctly that this field would be in the metadata of things built as part of the Red Hat Build of Quarkus, but not in the community built ones? We might want to have a mechanism to link those two (not by a literal hard link, but perhaps by relationship discovery, as we (sort of) do for extensions which moved namespace). If someone is looking at (say) the hibernate extension, we want to indicate "this extension isn't supported, but if you really want support, an extension with the same content is available over here, and that one would be supported." Whereas, if they're looking at (say) the pact extension, they have no commercial support options, no matter what build they're using.

A bit like this, on code.quarkus, but at the level of individual extensions:

[maxandersen]

the idea is *-support can be added at any level. The idea is to express who is providing support for it in * context.

i.e. redhat-support is used to mark that it is part of the redhat-support'ed extensions and then indicate what kind of level.
Others could make a microsoft-support tag and use that to express their kind of support. But we don't have a defined structure beyond that; it was intended to be used for targeted tooling that knew about those support options.

They are modelled at individual extensions but platforms is used to override/set them.

You'll need to scan the various platforms to get that overview/linkage.