Implementations Page UX Improvements.

[shaneutt]

The implementations page has gotten very large, and at this point is not helpful for the majority of users. It would be nice to re-organize it in such a way that it helps provide better categories of implementations, what their specializations are, what cloud providers they work on, have the ability to search and filter e.t.c.

I'm intentionally leaving this open ended, I want your opinions on how we can best improve this.

[danwinship]

It's especially bad from the perspective of a new user who wants to start using Gateway API in their cluster. The "Getting started with Gateway API" page starts out by telling you "Install a Gateway controller" and links to the implementations page, but it doesn't give any guidance beyond that. I know we don't want to have a "recommended" implementation like we do with ingress, but if we're going to say "here are 26 implementations with very little information about why you would prefer one to another", we might as well just say "lol, never mind, go install Ingress".

Some confusing bits:

• Some of the entries are obviously single-cloud-specific, but they're mixed in with the more generic ones.
• For the entries that aren't obviously single-cloud-specific, it's mostly not clear if that means they only support "bare metal", or if they also support clouds as well. (eg, if I'm on AWS, does that mean I have to use the AWS Gateway API Controller, or can I install Linkerd or Contour or something like that?)
• Similarly to the single-cloud-specific entries, some of the entries are Gateway implementations for existing networking products (eg, Cilium, Consul). These might be interesting to people planning out a new cluster (who haven't decided exactly what software they're going to run yet), but probably aren't interesting to someone looking for a Gateway implementation to install in their existing cluster (unless they happen to already be running the relevant bit of third-party software).
• Mixing together mesh and non-mesh implementations is probably not helpful to people looking to pick an implementation; presumably the user either wants a mesh or doesn't want a mesh, so having them listed separately would be more helpful.
• Application-specific gateways (eg STUNner) are interesting and worth listing, but should not be mixed in with the general-purpose gateways.

[howardjohn]

Mixing together mesh and non-mesh implementations is probably not helpful to people looking to pick an implementation; presumably the user either wants a mesh or doesn't want a mesh, so having them listed separately would be more helpful.

Mesh has its own section already (https://gateway-api.sigs.k8s.io/implementations/#service-mesh-implementation-status) -- at least some of the ones that are in mesh and the core list are single projects that offer both. I would like to keep the ones passing the ingress conformance tests in that section, as at least for Istio we encourage users to adopt it as a gateway even if not using 'mesh'

Agree on everything else though, I think that would be a big improvement