doc: fix vitepress sidebar (option 2 of 2)#39
Conversation
Order the pages in the sidebar so that they are (nearly) congruent with the schema agreed upon between Barbara and SAP. This is the first of two options I am creating on 13 Jul 2026. In this option, the Prysm page remains in the "Observability" folder. This is the location in which I found the Prysm page when I rearranged the other pages. It is reasonable to group the Prysm page under the rubric of "Observability", so in this commit I am leaving it where it is. The second option that I will create today will move the Prysm page between the Ceph page and the Chorus page in the "Cloud Storage" hierarchy. The second option is absolutely congruent with the schema agreed upon between Barbara and SAP. Either this commit (the first option) or the other commit (the second option) should be merged. The commit that is not merged should be rejected. Both options cannot be merged without creating a merge conflict. Signed-off-by: Zac Dover <zac.dover@clyso.com>
Order the pages in the sidebar so that they are (perfectly) congruent with the schema agreed upon between Barbara and SAP. This is the second of two options I am creating on 13 Jul 2026. This option moves the Prysm page so that it appears between the Ceph page and the Chorus page in the "Cloud Storage" hierarchy. The second option is absolutely congruent with the schema agreed upon between Barbara and SAP. In the first option (not this one), the Prysm page remains in the "Observability" folder. This is the location in which I found the Prysm page when I rearranged the other pages. It is reasonable to group the Prysm page under the rubric of "Observability", so in this commit I am leaving it where it is. Either this commit (the second option) or the other commit (the first option) should be merged. The commit that is not merged should be rejected. Both options cannot be merged without creating a merge conflict. Signed-off-by: Zac Dover <zac.dover@clyso.com>
|
Warning Review limit reached
Next review available in: 45 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (18)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Order the pages in the sidebar so that they are (perfectly) congruent
with the schema agreed upon between Barbara and SAP.
This is the second of two options I am creating on 13 Jul 2026. This
option moves the Prysm page so that it appears between the Ceph page and
the Chorus page in the "Cloud Storage" hierarchy. The second option is
absolutely congruent with the schema agreed upon between Barbara and
SAP.
In the first option (not this one), the Prysm page remains in the
"Observability" folder. This is the location in which I found the Prysm
page when I rearranged the other pages. It is reasonable to group the
Prysm page under the rubric of "Observability", so in this commit I am
leaving it where it is.
Either this commit (the second option) or the other commit (the first
option) should be merged. The commit that is not merged should be
rejected. Both options cannot be merged without creating a merge
conflict.
Signed-off-by: Zac Dover zac.dover@clyso.com