replace Jekyll link w/ Hugo relref

content/docs/contributing/_index.md

@@ -1,6 +1,6 @@
 ---
 title: Contributing
-linkTitle: Contributing 
+linkTitle: Contributing
 description: Gateway to the RAPIDS documentation content
 type: docs
 weight: 10
@@ -13,7 +13,7 @@ RAPIDS can only grow with community support and it is vital to include developer
 
 ## Getting started
 
-Welcome! We are excited you are here! Before you begin, we ask that everyone review the [Code of Conduct]({% link resources/conduct.md %}) before contributing.
+Welcome! We are excited you are here! Before you begin, we ask that everyone review the [Code of Conduct]({{< relref "../maintainers/conduct.md" >}}) before contributing.
 
 ### Your first issue
 
@@ -22,7 +22,7 @@ Welcome! We are excited you are here! Before you begin, we ask that everyone rev
 3. Comment on the issue saying you are going to work on it
 4. Code! Make sure to update unit tests!
 5. All RAPIDS projects are released under the Apache-2.0 license, so also make sure all source files that support comments include a copyright and the Apache-2.0 license text.
-6. When done, [create your pull request]({% link contributing/prs.md %})
+6. When done, [create your pull request]({{< relref "prs.md" >}})
 7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
 8. Wait for other developers to review your code and update code as needed
 9. Once reviewed and approved, a RAPIDS developer will merge your pull request
@@ -33,12 +33,12 @@ Remember, if you are unsure about anything, don't hesitate to comment on issues
 
 Once you have gotten your feet wet and are more comfortable with the code, follow these steps to find prioritized issues.
 
-All RAPIDS projects have project boards for triaging [issues]({% link releases/triage.md %}) and planning [features]({% link releases/planning.md %}).
+All RAPIDS projects have project boards for triaging [issues]({{< relref "../releases/triage.md" >}}) and planning [features]({{< relref "../releases/planning.md" >}}).
 
 ### More details
 
-Review the [Code Contributions]({% link contributing/code.md %}) page.
+Review the [Code Contributions]({{< relref "code.md" >}}) page.
 
 ## Issues or feedback
 
-File an issue [here](https://github.com/rapidsai/docs/issues/new) for any unexpected problems encountered or general feedback with any of the information on this site.
+File an issue [here](https://github.com/rapidsai/docs/issues/new) for any unexpected problems encountered or general feedback with any of the information on this site.

content/docs/contributing/code.md

@@ -11,14 +11,14 @@ weight: 10
 Outlines the best way for developers and the community to contribute to RAPIDS projects.
 
 Contributions can be made in three ways:
-- [File a bug report]({% link contributing/issues.md %})
-- [Suggest a new feature or improvement]({% link contributing/issues.md %})
+- [File a bug report]({{< relref "issues.md" >}})
+- [Suggest a new feature or improvement]({{< relref "issues.md" >}})
 - [Implement code for an issue](#your-first-issue)
 
 ### See also
 
-- [Issues]({% link contributing/issues.md %})
-- [Pull Requests]({% link contributing/prs.md %})
+- [Issues]({{< relref "issues.md" >}})
+- [Pull Requests]({{< relref "prs.md" >}})
 
 ## New developers
 
@@ -31,7 +31,7 @@ If you are new to RAPIDS, make sure to check out <https://rapids.ai/> to help un
 3. Comment on the issue saying you are going to work on it
 4. Code! Make sure to update unit tests!
 5. All RAPIDS projects are released under the Apache-2.0 license, so also make sure all source files that support comments include a copyright and the Apache-2.0 license text.
-6. When done, [create your pull request]({% link contributing/prs.md %})
+6. When done, [create your pull request]({{< relref "prs.md" >}})
 7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
 8. Wait for other developers to review your code and update code as needed
 9. Once reviewed and approved, a RAPIDS developer will merge your pull request
@@ -42,7 +42,7 @@ Remember, if you are unsure about anything, don't hesitate to comment on issues
 
 Once you have gotten your feet wet and are more comfortable with the code, follow these steps to find prioritized issues.
 
-All RAPIDS projects have project boards for triaging [issues]({% link releases/triage.md %}) and planning [features]({% link releases/planning.md %}).
+All RAPIDS projects have project boards for triaging [issues]({{< relref "../releases/triage.md" >}}) and planning [features]({{< relref "../releases/planning.md" >}}).
 
 ### What do I work on?
 
@@ -56,7 +56,7 @@ For all others:
 3. Select the highest priority issue that you are comfortable working on
 4. If you are in the RAPIDS org, assign the issue to yourself. If not, comment on the issue saying you are going to work on it
 5. Code! Make sure to update unit tests!
-6. When done, [create your pull request]({% link contributing/prs.md %})
+6. When done, [create your pull request]({{< relref "prs.md" >}})
 7. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
 8. Wait for other developers to review your code and update code as needed
 9. Once reviewed and approved, a RAPIDS developer will merge your pull request
@@ -65,6 +65,6 @@ For all others:
 
 1. Find the project board for the next release (named `[version] Release`)
 2. Scroll right to find the `PR-Needs Review`
-3. Review the PR (Make sure you follow the [Code of Conduct]({% link resources/conduct.md %}))
+3. Review the PR (Make sure you follow the [Code of Conduct]({{< relref "../maintainers/conduct.md" >}}))
 
 If you are project lead, also review pull requests in the `PR-Reviewer Approved` column and merge as needed.

content/docs/contributing/issues.md

@@ -1,6 +1,6 @@
 ---
 title: Issues
-linkTitle: Issues 
+linkTitle: Issues
 description: Gateway to the RAPIDS documentation content
 type: docs
 weight: 10
@@ -11,8 +11,8 @@ weight: 10
 Overview of the best practices for creating and updating issues for RAPIDS projects.
 
 ### See also
-- [Contributing Code]({% link contributing/code.md %})
-- [Pull Requests]({% link contributing/prs.md %})
+- [Contributing Code]({{< relref "code.md" >}})
+- [Pull Requests]({{< relref "prs.md" >}})
 
 ## Create an issue
 
@@ -64,7 +64,7 @@ If an issue is blocked due to another issue or pull request do the following:
 
 ## Lifecycle
 
-Issues are either assigned by team leads or picked in priority order. If you are unsure what to work on, follow this [guide]({% link contributing/code.md %}#what-do-i-work-on).
+Issues are either assigned by team leads or picked in priority order. If you are unsure what to work on, follow this [guide]({{< relref "code.md#what-do-i-work-on" >}}).
 
 When you begin work on an issue, update the labels to remove <span class="label" style="background: #bfd4f2; color: #44434d; text-transform: none">1 - On Deck</span> or <span class="label" style="background: #d4c5f9; color: #44434d; text-transform: none">0 - Backlog</span> and add <span class="label" style="background: #fef2c0; color: #44434d; text-transform: none">2 - In Progress</span>.
 

content/docs/contributing/prs.md

@@ -1,6 +1,6 @@
 ---
 title: Pull Requests
-linkTitle: PRs 
+linkTitle: PRs
 description: Gateway to the RAPIDS documentation content
 type: docs
 weight: 10
@@ -12,9 +12,9 @@ Overview of creating a pull request for a RAPIDS project.
 
 ### See also
 
-- [Issues]({% link contributing/issues.md %})
-- [Code Contributions]({% link contributing/code.md %})
-- [Changelog]({% link resources/changelog.md %})
+- [Issues]({{< relref "issues.md" >}})
+- [Code Contributions]({{< relref "code.md" >}})
+- [Changelog]({{< relref "../maintainers/changelog.md" >}})
 
 ## Create a pull request
 
@@ -58,7 +58,7 @@ The description should provide any context not found in the issue description.
 
 ### Comments
 
-All pull request comments and reviews must follow the [Code of Conduct]({% link resources/conduct.md %})
+All pull request comments and reviews must follow the [Code of Conduct]({{< relref "../maintainers/conduct.md" >}})
 
 ## Lifecycle
 

content/docs/maintainers/_index.md

@@ -10,28 +10,28 @@ RAPIDS projects use an established set of guidelines and procedures for all proj
 
 ## Release v{{ site.data.releases.nightly.version }} Schedule
 
-**NOTE:** *Dates are subject to change at anytime. Completed release schedules are posted [here]({% link releases/schedule.md %}).*
+**NOTE:** *Dates are subject to change at anytime. Completed release schedules are posted [here]({{< relref "../releases/schedule.md" >}}).*
 
 Phase | Start | End | Duration
 -- | -- | -- | --
 Development (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.nightly.cudf_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_dev.days }} days
 Development (others) | {{ site.data.releases.nightly.other_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_dev.days }} days
-[Burn Down]({% link releases/process.md %}#burn-down)(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.days }} days
-[Burn Down]({% link releases/process.md %}#burn-down) (others) | {{ site.data.releases.nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.days }} days
-[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.days }} days
-[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (others) | {{ site.data.releases.nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.days }} days
-[Release]({% link releases/process.md %}#releasing) | {{ site.data.releases.nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.days }} days
+[Burn Down]({{< relref "../releases/process.md#burn-down" >}})(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_burndown.days }} days
+[Burn Down]({{< relref "../releases/process.md#burn-down" >}}) (others) | {{ site.data.releases.nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_burndown.days }} days
+[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.cudf_codefreeze.days }} days
+[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (others) | {{ site.data.releases.nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.other_codefreeze.days }} days
+[Release]({{< relref "../releases/process.md#releasing" >}}) | {{ site.data.releases.nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.nightly.release.days }} days
 
 ## _PROPOSED_ Release v{{ site.data.releases.next_nightly.version }} Schedule
 
 Phase | Start | End | Duration
 -- | -- | -- | --
 Development (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.next_nightly.cudf_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_dev.days }} days
 Development (others) | {{ site.data.releases.next_nightly.other_dev.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_dev.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_dev.days }} days
-[Burn Down]({% link releases/process.md %}#burn-down)(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.next_nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.days }} days
-[Burn Down]({% link releases/process.md %}#burn-down) (others) | {{ site.data.releases.next_nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.days }} days
-[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.next_nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.days }} days
-[Code Freeze/Testing]({% link releases/process.md %}#code-freeze) (others) | {{ site.data.releases.next_nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.days }} days
-[Release]({% link releases/process.md %}#releasing) | {{ site.data.releases.next_nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.days }} days
+[Burn Down]({{< relref "../releases/process.md#burn-down" >}})(cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) | {{ site.data.releases.next_nightly.cudf_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_burndown.days }} days
+[Burn Down]({{< relref "../releases/process.md#burn-down" >}}) (others) | {{ site.data.releases.next_nightly.other_burndown.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_burndown.days }} days
+[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (cuDF/RMM/rapids-cmake/cugraph-ops/raft/dask-cuda/ucx-py) [^1] | {{ site.data.releases.next_nightly.cudf_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.cudf_codefreeze.days }} days
+[Code Freeze/Testing]({{< relref "../releases/process.md#code-freeze" >}}) (others) | {{ site.data.releases.next_nightly.other_codefreeze.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.other_codefreeze.days }} days
+[Release]({{< relref "../releases/process.md#releasing" >}}) | {{ site.data.releases.next_nightly.release.start | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.end | date: "%a, %b %e, %Y" }} | {{ site.data.releases.next_nightly.release.days }} days
 
 [^1]: Cross-library dependencies are pinned during this time-frame. For example: Dask and Distributed.

content/docs/maintainers/burn-down-guide.md

@@ -8,7 +8,7 @@ weight: 10
 
 ## Overview
 
-This is a guide for the steps required to perform at the start of [burn down]({% link releases/process.md %}#burn-down).
+This is a guide for the steps required to perform at the start of [burn down]({{< relref "../releases/process.md#burn-down" >}}).
 
 Given the current development version is `v0.A.0`, then the next version is `v0.B.0` where `B=A+1`.
 

content/docs/maintainers/forward-merger.md

@@ -35,8 +35,8 @@ git commit -am "Merge branch-{{ site.data.releases.stable.version }} into branch
 git push <personal fork> branch-{{ site.data.releases.nightly.version }}-merge-{{ site.data.releases.stable.version }}
 ```
 
-Once this is done, open a PR that targets the new default branch (`branch-{{ site.data.releases.nightly.version }}` in this example) with your changes. 
+Once this is done, open a PR that targets the new default branch (`branch-{{ site.data.releases.nightly.version }}` in this example) with your changes.
 
-**IMPORTANT**: When merging this PR, do not use the [auto-merger]({% link resources/auto-merger.md %}) (i.e. the `/merge` comment). Instead, an admin must manually merge by changing the merging strategy to `Create a Merge Commit`. Otherwise, history will be lost and the branches become incompatible.
+**IMPORTANT**: When merging this PR, do not use the [auto-merger]({{< relref "auto-merger.md" >}}) (i.e. the `/merge` comment). Instead, an admin must manually merge by changing the merging strategy to `Create a Merge Commit`. Otherwise, history will be lost and the branches become incompatible.
 
-Once this PR is approved and merged, the original forward-merger PR should automatically be merged since it will contain the same commit hashes.
+Once this PR is approved and merged, the original forward-merger PR should automatically be merged since it will contain the same commit hashes.

content/docs/maintainers/git.md

@@ -12,9 +12,9 @@ Details on our git branching method used for RAPIDS and our style conventions fo
 
 ### See also
 
-* [Versioning and Tagging]({% link resources/versions.md %})
-* [Hotfix releases]({% link releases/hotfix.md %})
-* [Major and minor releases]({% link releases/process.md %})
+* [Versioning and Tagging]({{< relref "versions.md" >}})
+* [Hotfix releases]({{< relref "hotfix.md" >}})
+* [Major and minor releases]({{< relref "process.md" >}})
 
 ## Git branching
 
@@ -24,7 +24,7 @@ Our development approach involves protecting the `main` branch so that it become
 
 ### Development workflow
 
-All PRs are merged into a release branch named `branch-M.B` where `M` is the major version and `B` is the minor version number. Release branches are created from the previous release branch when the decision has been made to **freeze** the release. 
+All PRs are merged into a release branch named `branch-M.B` where `M` is the major version and `B` is the minor version number. Release branches are created from the previous release branch when the decision has been made to **freeze** the release.
 
 To **freeze** a release branch is to stop new development for the release, and focus on completing outstanding features and any bugs discovered from testing. Once this **freeze** happens a new branch `branch-M.C` (where `C=B+1`) is created so development can continue. Updates to `branch-M.B` can be merged as needed to `branch-M.C`, but generally will wait until the release is finished. This means that `branch-M.X` (where `X` is the highest minor version) the latest and greatest code.
 
@@ -62,4 +62,4 @@ Files that are `not required` should be stored in S3 so the limited number of de
 
 It is important to choose the appropriate storage mechanism from the beginning because transitioning from git to git LFS or S3 requires rewriting git history.
 
-If you need data uploaded to S3, simply file an Ops issue.
+If you need data uploaded to S3, simply file an Ops issue.