Add provisional GEPs back to TOC

[rikatz]

What type of PR is this?
/kind documentation

What this PR does / why we need it:
Adds Provisional GEPs back to Website navigation

Which issue(s) this PR fixes:

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rikatz
Once this PR has been reviewed and has the lgtm label, please assign danwinship for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rikatz]

/cc @kflynn

As you wish :)

[kflynn]

/lgtm

Thanks @rikatz! I think this is really important as we start looking to have things start in Provisional in order to make it into Experimental.

[robscott]

/hold

I was actually one of the people that argued for the removal of provisional from navigation. This was for a few reasons:

1. We are accepting a large number of provisional GEPs, and many of them may be dead ends/go nowhere. Highlighting these despite their provisional nature could lead to more confusion and/or disappointment.
2. The existing GEP navigation is already overwhelming, this will only get worse as we add an increasing number of provisional GEPs.

If we want to include provisional GEPs somewhere on the website, filled with lots of disclaimers about what it means for something to be provisional, I can be OK with that, I'd just rather have it somewhere less prominent and with more warnings about the nature of provisional proposals.

[kflynn]

Sorry @robscott, I remember seeing your comments on this now and spaced on it. 🤦‍♂️

Any suggestions on what you think would be reasonable for the presentation? If we’re having provisional be an important part of the release cycle, we need to have them visible somehow.

[kflynn]

(Maybe we should drop the TOC in the sidebar, and instead have links to category pages that then list the individual GEPs. 🤔)

[rikatz]

(Maybe we should drop the TOC in the sidebar, and instead have links to category pages that then list the individual GEPs. 🤔)

I can rework this PR to follow this approach instead, rendering the pages experimental, provisional, etc with the GEPs. Will take me some time tho :)

[robscott]

(Maybe we should drop the TOC in the sidebar, and instead have links to category pages that then list the individual GEPs. 🤔)

I'm probably the only one with this workflow, but because I can't remember the numbers of GEPs, I really pretty heavily on the ability to "find in page" based on that navigation to find a GEP. I'm sure there's a better way though?

If we’re having provisional be an important part of the release cycle, we need to have them visible somehow.

Agree, maybe a separate page for GEPs that are provisional, rejected, or deferred that comes with the appropriate caveats.

[youngnick]

I think having the TOC of all GEPs on the right, and the TOC within the GEP on the left is probably overkill. Removing the right-hand TOC might help with making this easier to read.

That said, I'm also very supportive of splitting out the "safe to read" GEPs (Memorandum, Experimental and Standard) from the "hey, there are caveats" GEPs (everything else).

[robscott]

+1 to everything @youngnick said above. Maybe to make this a bit more sustainable, we split this into two distinct sections and each of those sections has an index page which lists each GEP, potentially along with some metadata now that we're already auto-generating it from the YAML (thanks @rikatz).

With that in place I think it would be very reasonable to at least stop auto-expanding the lists of GEPs in the navigation.

[kflynn]

To be clear, I was suggesting the idea that the "Enhancements" section would no longer have multiple levels of expansion. Instead e.g. "Implementable" would just be a link to a page that looked like

---

Implementable GEPs

These are all features that have reached the point that we think they can be implemented, but maybe we'll change them dramatically later.

• GEP-1494: HTTP Auth in Gateway API
• GEP-3388: Retry Budgets
• GEP-3567: Gateway TLS Updates for HTTP/2 Connection Coalescing
• GEP-3793: Default Gateways
• GEP-3949: Mesh Resource

---

We'd then have a page for Dangerous Stuff:

---

GEPs You Can't Rely On

Provisional

These may or may not get accepted into experimental.

• GEP-22222: The MoonPhase HTTPRoute filter
• GEP-22223: Adopting Magical Cryptography
• ...

Withdrawn

These GEPs have been withdrawn by their authors.

• ...

etc.

...

---

My reasoning here is just that the auto-expanding sidebar gets more and more unwieldly as we add things, and (to Rob's point) searching gets more obnoxious. (Of course it could as easily be a single page with sections -- the point is getting it out of the sidebar.)

🤷‍♂️ An idea, anyway, I'm not particularly wedded to it.

[k8s-ci-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.