[chore] Fix link fragments (#293)

This commit is contained in:
Patrice Chalin 2025-02-25 14:05:00 -05:00 committed by GitHub
parent e1cfca7dce
commit 706bc26d5f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
11 changed files with 119 additions and 116 deletions

View File

@ -3,9 +3,6 @@
{
"pattern": "^http://localhost"
},
{
"pattern": "^#"
},
{
"pattern": "^https://(www|docs).tremor.rs"
},

View File

@ -4,6 +4,7 @@ tags: backstage
created: 2023-09-01
modified: 2023-11-28
author: Dave Welsch (@dwelsch-esi)
cSpell:ignore: clotributor dwelsch Welsch runbooks WCAG
---
# Introduction
@ -95,7 +96,7 @@ to their area of concern:
- [Project documentation][proj-doc]
- [Contributor documentation][contributor-doc]
- [Website and documentation infrrastructure][website]
- [Website and documentation infrastructure][website]
Examples of CNCF documentation that demonstrates the analysis criteria are
linked from the [Criteria][cncf-doc-criteria] specification.
@ -277,10 +278,10 @@ documentation set, but the nature of Backstage makes it especially important
here.
The example roles given in the [comments][proj-doc-comments] have been carried
over to the [Implementation][implementation] section. Contributors with a
greater understanding of how Backstage is used should feel free to modify this
list if it serves the needs of the project, keeping in mind that the purpose of
the user roles is to organize the task-based documentation.
over to [Implementation][implementation-doc]. Contributors with a greater
understanding of how Backstage is used should feel free to modify this list if
it serves the needs of the project, keeping in mind that the purpose of the user
roles is to organize the task-based documentation.
### Develop instructional documentation
@ -405,7 +406,7 @@ There is an active [Discussions][backstage-discussion] board in the GitHub repo.
page][backstage-github-community] on GitHub. Help resources are not linked from
the Getting Started documentation.
Backstage is listed in the [Clotributor][clotributor] tool.
Backstage is listed in the [Clotributor][] tool.
### Project governance documentation
@ -416,8 +417,7 @@ Governance is clearly documented in [GOVERNANCE.md][backstage-governance].
As an open source project, Backstage looks healthy and well run.
The only recommendation here is to disentangle the contributor documentation
from the product documentation, as described in the [Information architecture
recommendations][info-arch-recommend].
from the product documentation.
# Website
@ -577,14 +577,12 @@ Improve compliance in these areas:
- **Images** should have alternative text.
- **Links** should have discernible text.
<!--- References --->
[backstage-backstage]: https://github.com/backstage/backstage
[backstage-community]: https://backstage.io/community
[backstage-contrib]:
https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md
[backstage-demo]:
https://demo.backstage.io/catalog?filters%5Bkind%5D=component&filters%5Buser%5D=owned
https://demo.backstage.io/catalog?no-link-check&filters%5Bkind%5D=component&filters%5Buser%5D=owned
[backstage-discussion]: https://discord.gg/backstage-687207715902193673
[backstage-doc-contrib]:
https://backstage.io/docs/contribute/getting-involved#write-documentation-or-improve-the-website
@ -628,8 +626,6 @@ Improve compliance in these areas:
[contrib-doc-rec]: #recommendations-contributor-documentation
[contributor-doc]: #contributor-documentation
[doc-survey]: backstage-doc-survey.csv
[implementation]: #implementation
[info-arch-recommend]: #recommendations
[proj-doc-comments]: #comments-project-documentation
[proj-doc-rec]: #recommendations-project-documentation
[proj-doc]: #project-documentation

View File

@ -3,7 +3,7 @@
## API
In the Backstage [Catalog](#catalog), an API is an [entity](#entity)
representing a boundary between two [compnents](#component).
representing a boundary between two [components](#component).
https://backstage.io/docs/features/software-catalog/system-model
@ -41,7 +41,7 @@ declarative APIs exemplify this approach."
## Cloud Native Computing Foundation
A foundation dedicated to the promotion and advancement of
[Cloud Native Computing](#Cloud-Native-Computing). The mission of the Cloud
[Cloud Native Computing](#cloud-native-computing). The mission of the Cloud
Native Computing Foundation (CNCF) is "to make cloud native computing
ubiquitous"
([CNCF Charter](https://github.com/cncf/foundation/blob/main/charter.md)).
@ -91,7 +91,7 @@ https://backstage.io/docs/features/software-catalog/system-model
## Entity
What is cataloged in the Backstage Software Catalog. An entity is identified by
[kind](#Kind), [namespace](#Namespace), and name.
[kind](#kind), [namespace](#namespace), and name.
## Evaluator
@ -106,7 +106,7 @@ with another software system. A [user role](#user-role).
## Kind
Classification of an [entity](#Entity) in the Backstage Software Catalog, for
Classification of an [entity](#entity) in the Backstage Software Catalog, for
example _service_, _database_, and _team_.
## Kubernetes Plugin
@ -126,7 +126,7 @@ organize [entities](#entity).
## Objective
A high level goal of a [user role](#User-Role) interacting with Backstage. Some
A high level goal of a [user role](#user-role) interacting with Backstage. Some
goals of the _administrator_ user role, for example, are to maintain an instance
("app") of Backstage; to add and update functionality via plugins; and to
troubleshoot issues.
@ -147,8 +147,8 @@ the core features, are implemented as plugins.
## Procedure
A set of actions that accomplish a goal, usually as part of a
[use case](#Use-Case). A procedure can be high-level, containing other
procedures, or can be as simple as a single [task](#Task).
[use case](#use-case). A procedure can be high-level, containing other
procedures, or can be as simple as a single [task](#task).
## Resource
@ -160,13 +160,13 @@ https://backstage.io/docs/features/software-catalog/system-model
## Role
See [User Role](#User-Role).
See [User Role](#user-role).
## Search
A Backstage plugin that provides a framework for searching a Backstage
[app](#app), including the [Software Catalog](#Software-Catalog) and
[TechDocs](#TechDocs). One of the core features of Backstage.
[app](#app), including the [Software Catalog](#software-catalog) and
[TechDocs](#techdocs). One of the core features of Backstage.
## Software Catalog
@ -190,7 +190,7 @@ https://backstage.io/docs/features/software-catalog/system-model
## Task
A low-level step-by-step [Procedure](#Procedure).
A low-level step-by-step [Procedure](#procedure).
## TechDocs
@ -200,7 +200,7 @@ Backstage.
## Use Case
A purpose for which a [user role](#User-Role) interacts with Backstage. Related
A purpose for which a [user role](#user-role) interacts with Backstage. Related
to [Objective](#objective): An objective is _what_ the user wants to do; a use
case is _how_ the user does it.

View File

@ -1,12 +1,13 @@
---
title: Implementing Backstage Doc Improvements
tags: backstage
cSpell:ignore: rigeur runbooks toolkits
---
# Introduction
This document provides actionable suggestions for improving the Backstage
technical documentaiton.
technical documentation.
For an analysis and general discussion of recommendations on Backstage technical
documentation, see [backstage-analysis.md][backstage-analysis]].
@ -142,7 +143,7 @@ The following artifacts should be written and made findable for administrators.
- Install and configure Backstage plugins
- Manage the many software dependencies for Backstage and its plugins
- Maintain the Backstage database
- Upgrade and downgrade the Backstage release verison
- Upgrade and downgrade the Backstage release version
- Troubleshoot common problems
- Tune server performance
@ -153,7 +154,7 @@ The following artifacts should be written and made findable for developers.
1. A getting started guide for developers. Provide a clear work path that
describes how to:
1. Downloead and install any necessary software components
1. Download and install any necessary software components
1. Integrate Backstage with an existing development environment
1. A User Guide for developers. Provide clear instructions for these tasks:
@ -173,7 +174,7 @@ issues. For integrators, at a high level, a program should be undertaken to:
1. Organize integrator tasks from most basic and common (write a simple plugin;
decide between backend and frontend plugin) to more complex (integrate with
external systems; use a proxy; implement authentication).
2. Where possible, using the exisitng documentation as a starting point, write
2. Where possible, using the existing documentation as a starting point, write
step-by-step procedures for discrete integration tasks (starting with how to
write a basic plugin).
3. Organize existing reference and conceptual information (such as API

View File

@ -1,3 +1,7 @@
---
cSpell:ignore: flipside
---
# Backstage Insights
This document briefly summarizes the research, branded "Backstage Insight," done
@ -21,7 +25,7 @@ Adoption here means:
3. Automate development using Backstage, including integrating Backstage with
other development support systems.
3. Backstage must be recognized throughout the organization as the "source of
truth" about all software development within the organizaiton.
truth" about all software development within the organization.
### Barriers to Adoption
@ -85,7 +89,7 @@ number one outcome for both internal and external users was to **maintain clear
ownership of software**.
For external adopters, other top outcomes were consistent with _improving the
maturity level of their development practices_, for example standarizing
maturity level of their development practices_, for example standardizing
software development practices and increasing collaboration. For internal
adopters, other top outcomes were goals that relied on already-mature
development practices, for example improving monitoring and tracking costs. The

View File

@ -45,7 +45,7 @@ including:
- _Evaluator_: Someone trying to determine whether etcd is appropriate for their
product, project, or organization.
- _Admin or Operator_: Someonereponsible for setting up and maintaining a
- _Admin or Operator_: Someone responsible for setting up and maintaining a
standalone (non-Kubernetes-backstore) production etcd service.
- _Kubernetes Admin_: Someone responsible for a Kubernetes cluster using etcd as
a backstore.
@ -265,7 +265,7 @@ Sections to be added to the table of contents.
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Reference | A library of reference documents: APIs, CLIs, configuration options, and anything else a user might need to look up to complete a task. |
| Troubleshooting | A list of procedures for diagnosing and fixing problems. |
| Release Notes | The cumulative release notes for the major and minor release. See [Release Notes](#add-release-notes-to-new-releases). |
| Release Notes | The cumulative release notes for the major and minor release. |
### Remove pages
@ -279,7 +279,7 @@ that page is listed as "Redundant with". Page URLs are relative to
| -------------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------- | ----------------------------------------------------------------------------- |
| demo/ | | op-guide/authentication/authentication/ | Remove |
| dev-internal/discovery_protocol/ | op-guide/clustering/ | dev-guide/discovery_protocol/ | Remove |
| /dev-guide/interacting_v3/ | dev-guide/local_cluster/ | tutorials/\*.md | Consolidate under "Tasks". See [Tutorials](#tutorials) |
| /dev-guide/interacting_v3/ | dev-guide/local_cluster/ | tutorials/\*.md | [Consolidate under "Tasks"](#issue-convert-tutorials-to-tasks) |
| op-guide/recovery/ | op-guide/failures/, op-guide/runtime-configuration/, op-guide/runtime-reconf-design/ | | Incorporate into Troubleshooting guide |
| op-guide/data_corruption/ | op-guide/monitoring/ | | Incorporate into Troubleshooting guide |
| upgrades/ | | | Remove or archive old upgrade paths if they're no longer needed or supported. |

View File

@ -1,10 +1,9 @@
---
title: KEDA Documentation Analysis
tags: kdeda
created: 2024-02-23
modified: 2024-04-09
author: Dave Welsch (@dwelsch-esi)
cSpell:ignore: Welsch dwelsch pastable
cSpell:ignore: Welsch dwelsch pastable servicedesk
---
# Introduction
@ -383,9 +382,9 @@ KEDA is a **graduated** project of CNCF. This means that the project should have
### Single-source requirement
Source files for all website pages reside in a **single repo**. However, some
user documentation pages (speciifically, "Getting started" topics linked from
the main (kedacore/keda) repo) would better serve users if they were moved to
the tech docs on the website.
user documentation pages (specifically, "Getting started" topics linked from the
main (kedacore/keda) repo) would better serve users if they were moved to the
tech docs on the website.
Website files are all in the website repo.
@ -403,7 +402,7 @@ sandbox, incubating, graduated and archived.
| Maturity | Requirement | Met? |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |
| Sandbox | Majority of [Website guidelines](../../docs/website-guidelines-checklist.md) satisfied | Yes |
| Sandbox | [Docs assessment](../../docs/analysis/howto.md) [cncf-servicedesk] completed. | Yes |
| Sandbox | [Docs assessment](../../docs/analysis/howto.md) [CNCF-servicedesk] completed. | Yes |
| Sandbox | **Project documentation** exists somewhere. It is acceptable at this maturity level to link out to documentation that hasn't yet been integrated into the website. (May still be in the project GitHub repo, for example.) | Yes |
| Incubating | All [Website guidelines](../../docs/analysis/criteria.md#website) satisfied | Yes |
| Incubating | Request docs (re-)assessment through CNCF [service desk](https://servicedesk.cncf.io/) | Yes |
@ -538,3 +537,5 @@ Explicitly list and solicit maintainers and contributors for documentation.
No recommendations.
<!--- References --->
[CNCF-servicedesk]: https://servicedesk.cncf.io

View File

@ -6,7 +6,7 @@ tags: keda
# Introduction
This document provides actionable suggestions for improving the KEDA technical
documentaiton.
documentation.
For an analysis and general discussion of recommendations on KEDA technical
documentation, see [keda-analysis.md][keda-analysis].
@ -26,7 +26,7 @@ such, and pertain to legal requirements such as copyright and licensing issues.
The documentation recommendations for this project are:
- [Reorganize the table of contents (TOC)](#reorganize-the-table-of-contents-toc)
- [Reorganize the table of contents (TOC)](#reorganize-the-table-of-contents)
- [Write a glossary](#write-a-glossary)
- [Add "How to set up a scaler" to the Operator guide](#add-how-to-set-up-a-scaler-to-the-operator-guide)
- [Write a New User workflow](#write-a-new-user-workflow)
@ -41,7 +41,7 @@ Reorganize the Table of Contents to:
- Better welcome and orient new users
- Separate user rules (personas), if there are more than one
- Improve findability and access to tasks and procedures
- Improve the ease of finding and accessing tasks and procedures
- Separate conceptual, task, and reference information
In general, follow these principles when reorganizing the documentation:
@ -77,18 +77,18 @@ Here is a proposed outline for the tech doc Table of Contents:
current "KEDA Documentation" heading)
- [Deploying KEDA](https://keda.sh/docs/2.13/deploy/)
- Prerequisites (https://keda.sh/docs/2.13/operate/cluster/#requirements)
- [Deploying with Helm](#helm)
- [Installing](#install)
- [Uninstalling](#uninstall)
- [Deploying with Operator Hub](#operatorhub)
- [Installing](#install-1)
- [Uninstalling](#uninstall-1)
- [Deploying using the deployment YAML files](#yaml)
- [Installing](#install-2)
- [Uninstalling](#uninstall-2)
- [Deploying KEDA on MicroK8s](#microk8s)
- [Installing](#install-3)
- [Uninstalling](#uninstall-3)
- [Deploying with Helm](?no-link-check#helm)
- [Installing](?no-link-check#install)
- [Uninstalling](?no-link-check#uninstall)
- [Deploying with Operator Hub](?no-link-check#operatorhub)
- [Installing](?no-link-check#install-1)
- [Uninstalling](?no-link-check#uninstall-1)
- [Deploying using the deployment YAML files](?no-link-check#yaml)
- [Installing](?no-link-check#install-2)
- [Uninstalling](?no-link-check#uninstall-2)
- [Deploying KEDA on MicroK8s](?no-link-check#microk8s)
- [Installing](?no-link-check#install-3)
- [Uninstalling](?no-link-check#uninstall-3)
- Hello, KEDA (write a procedure for a simplest-possible use case for users to
get started on - something like
https://github.com/kedacore/sample-hello-world-azure-functions)
@ -98,7 +98,7 @@ Here is a proposed outline for the tech doc Table of Contents:
Getting Started)
- Usage Scenarios
- [Scaling with RabbitMQ and Go](https://github.com/kedacore/sample-go-rabbitmq)
- [Scaling with Azure Functions and Kafka on Openshift 4](https://github.com/kedacore/sample-azure-functions-on-ocp4)
- [Scaling with Azure Functions and Kafka on OpenShift 4](https://github.com/kedacore/sample-azure-functions-on-ocp4)
- ... and so on.
- [Admission Webhooks](https://keda.sh/docs/2.13/operate/admission-webhooks/)
- Prevention Rules
@ -196,18 +196,18 @@ annotated to illustrate this point:
the differences here to help the new user decide. Also, if prerequisites
depend on the deployment type, you can optionally put a Prerequisites
section in each deployment procedure rather than here._
- [Deploying with Helm](#helm)
- [Installing](#install)
- [Uninstalling](#uninstall) \*
- [Deploying with Operator Hub](#operatorhub)
- [Installing](#install-1)
- [Uninstalling](#uninstall-1)
- [Deploying using the deployment YAML files](#yaml)
- [Installing](#install-2)
- [Uninstalling](#uninstall-2)
- [Deploying KEDA on MicroK8s](#microk8s)
- [Installing](#install-3)
- [Uninstalling](#uninstall-3)
- [Deploying with Helm](?no-link-check#helm)
- [Installing](?no-link-check#install)
- [Uninstalling](?no-link-check#uninstall) \*
- [Deploying with Operator Hub](?no-link-check#operatorhub)
- [Installing](?no-link-check#install-1)
- [Uninstalling](?no-link-check#uninstall-1)
- [Deploying using the deployment YAML files](?no-link-check#yaml)
- [Installing](?no-link-check#install-2)
- [Uninstalling](?no-link-check#uninstall-2)
- [Deploying KEDA on MicroK8s](?no-link-check#microk8s)
- [Installing](?no-link-check#install-3)
- [Uninstalling](?no-link-check#uninstall-3)
- Hello, KEDA (write a procedure for a simplest-possible use case for users to
get started on - something like
https://github.com/kedacore/sample-hello-world-azure-functions) _analogous

View File

@ -1,7 +1,7 @@
---
title: KEDA Umbrella Issue
tags: keda
cSpell:ignore: findability
cSpell:ignore: externalscaler findability
---
# Overview
@ -84,18 +84,18 @@ into multiple pages, one for each procedure.
This reduces frustration. Also, if prerequisites depend on the deployment
type, you can optionally put a Prerequisites section in each deployment
procedure rather than here._
- [Deploying with Helm](#helm)
- [Installing](#install)
- [Uninstalling](#uninstall)
- [Deploying with Operator Hub](#operatorhub)
- [Installing](#install-1)
- [Uninstalling](#uninstall-1)
- [Deploying using the deployment YAML files](#yaml)
- [Installing](#install-2)
- [Uninstalling](#uninstall-2)
- [Deploying KEDA on MicroK8s](#microk8s)
- [Installing](#install-3)
- [Uninstalling](#uninstall-3)
- [Deploying with Helm](?no-link-check#helm)
- [Installing](?no-link-check#install)
- [Uninstalling](?no-link-check#uninstall)
- [Deploying with Operator Hub](?no-link-check#operatorhub)
- [Installing](?no-link-check#install-1)
- [Uninstalling](?no-link-check#uninstall-1)
- [Deploying using the deployment YAML files](?no-link-check#yaml)
- [Installing](?no-link-check#install-2)
- [Uninstalling](?no-link-check#uninstall-2)
- [Deploying KEDA on MicroK8s](?no-link-check#microk8s)
- [Installing](?no-link-check#install-3)
- [Uninstalling](?no-link-check#uninstall-3)
- Hello, KEDA (write a procedure for a simplest-possible use case for users to
get started on - something like
https://github.com/kedacore/sample-hello-world-azure-functions) _analogous
@ -128,7 +128,7 @@ or provide a starting point.
["Write 'Setting Up a Scaler'"](#write-setting-up-a-scaler))
- Usage Scenarios
- [Scaling with RabbitMQ and Go](https://github.com/kedacore/sample-go-rabbitmq)
- [Scaling with Azure Functions and Kafka on Openshift 4](https://github.com/kedacore/sample-azure-functions-on-ocp4)
- [Scaling with Azure Functions and Kafka on OpenShift 4](https://github.com/kedacore/sample-azure-functions-on-ocp4)
- ... and so on.
- [Admission Webhooks](https://keda.sh/docs/2.13/operate/admission-webhooks/)
- Prevention Rules

View File

@ -7,12 +7,12 @@
## 目次
- [スタイルガイド](#スタイルガイド)
- [固有の用語](#固有の用語)
- [](#例)
- [レビュー](#レビュー)
- [プロジェクト](#プロジェクト)
- [コミュニケーション](#コミュニケーション)
- [スタイルガイド](?no-link-check#スタイルガイド)
- [固有の用語](?no-link-check#固有の用語)
- [](?no-link-check#例)
- [レビュー](?no-link-check#レビュー)
- [プロジェクト](?no-link-check#プロジェクト)
- [コミュニケーション](?no-link-check#コミュニケーション)
## スタイルガイド
@ -50,7 +50,7 @@ CNCFのプロジェクト特有の用語については、原則として英語
## レビュー
ローカライゼーションのPRを作成した際は、ローカライゼーションレビュアーにレビューを依頼してください。各リポジトリのレビュアーは、[プロジェクト](#プロジェクト)の表を参考にしてください。
ローカライゼーションのPRを作成した際は、ローカライゼーションレビュアーにレビューを依頼してください。各リポジトリのレビュアーは、[プロジェクト](?no-link-check#プロジェクト)の表を参考にしてください。
2人以上のローカライゼーションレビュアーからの承認を得ることを推奨します。
ローカライゼーションレビュアーからの承認を得た後、各リポジトリのメンテナーにPRのマージを依頼してください。

View File

@ -98,10 +98,10 @@ on: - Localization / Internationalization
The folder based method of versioning can make the website code more complex.
One of the things that make this an interesting example is how Batard (2020,
L8-L18)<sup>[2](#footnote2)</sup> manages the navigation in the
`/site/layouts/docs/versions.html` file, particularly the use of the `replace`
function to ensure that when the links in the dropdown menu are built, the
versioned links reflect the currently loaded page:
L8-L18)[^2] manages the navigation in the `/site/layouts/docs/versions.html`
file, particularly the use of the `replace` function to ensure that when the
links in the dropdown menu are built, the versioned links reflect the currently
loaded page:
[velero.io](https://velero.io/) `/site/layouts/docs/versions.html`
@ -120,7 +120,7 @@ versioned links reflect the currently loaded page:
</div>
```
Batard (2020, L8-L18)<sup>[2](#footnote2)</sup>
Batard (2020, L8-L18)[^2]
Folder based versioning can make site _configuration_ less complex.
@ -137,7 +137,7 @@ velero.io `velero/site/config.yaml`
```
Brubaker et al. (2020, L14-L20)<sup>[3](#footnote3)</sup>
Brubaker et al. (2020, L14-L20)[^3]
### Subdomain based
@ -177,7 +177,7 @@ configuration:
</div>
```
Pursley et al. (2020, L4-L9)<sup>[4](#footnote4)</sup>
Pursley et al. (2020, L4-L9)[^4]
The dropdown example is made simpler because the config is more complex and
because the server setup is more complex.
@ -200,7 +200,7 @@ docsbranch = "release-1.19"
url = "https://v1-19.docs.kubernetes.io"
```
Bannister et al. (2020, L180-L192)<sup>[1](#footnote1)</sup>
Bannister et al. (2020, L180-L192)[^1]
## Summary
@ -221,25 +221,29 @@ method is likely the best method to balance versioning considerations.
## References / Credits
<a name="footnote1">1</a>: [Bannister, T.](https://github.com/sftim) et al.
(2020, December 23). kubernetes/website. GitHub. Retrieved February 2, 2021 from
[https://github.com/kubernetes/website/blob/ 7462297ee388332a7b0d27625929fbf44d0c1ea9/config.toml](https://github.com/kubernetes/website/blob/7462297ee388332a7b0d27625929fbf44d0c1ea9/config.toml)
[^1]:
[Bannister, T.](https://github.com/sftim) et al. (2020, December 23).
kubernetes/website. GitHub. Retrieved February 2, 2021 from
[https://github.com/kubernetes/website/blob/ 7462297ee388332a7b0d27625929fbf44d0c1ea9/config.toml](https://github.com/kubernetes/website/blob/7462297ee388332a7b0d27625929fbf44d0c1ea9/config.toml)
<a name="footnote2">2</a>: [Batard, T.](https://github.com/tbatard) (2020,
August 13). _vmware-tanzu/velero_. GitHub. Retrieved January 19, 2021 from
[https://github.com/vmware-tanzu/velero/blob/ db403c6c54b0048fada2b5db628c44be4ac0fd79/site/layouts/docs/versions.html](https://github.com/vmware-tanzu/velero/blob/db403c6c54b0048fada2b5db628c44be4ac0fd79/site/layouts/docs/versions.html)
[^2]:
[Batard, T.](https://github.com/tbatard) (2020, August 13).
_vmware-tanzu/velero_. GitHub. Retrieved January 19, 2021 from
[https://github.com/vmware-tanzu/velero/blob/ db403c6c54b0048fada2b5db628c44be4ac0fd79/site/layouts/docs/versions.html](https://github.com/vmware-tanzu/velero/blob/db403c6c54b0048fada2b5db628c44be4ac0fd79/site/layouts/docs/versions.html)
<a name="footnote3">3</a>: [Brubaker, N.](https://github.com/nrb),
[Rosland, J.](https://github.com/jonasrosland),
[Thompson, C.](https://github.com/carlisia),
[Batard, T.](https://github.com/tbatard) (2020, September 16).
_vmware-tanzu/velero_. GitHub. Retrieved February 2, 2021 from
[https://github.com/vmware-tanzu/velero/blob/1fd49f4fd66ecf6cd959ce258efbd9a549d8902b/site/config.yaml](https://github.com/vmware-tanzu/velero/blob/1fd49f4fd66ecf6cd959ce258efbd9a549d8902b/site/config.yaml)
[^3]:
[Brubaker, N.](https://github.com/nrb),
[Rosland, J.](https://github.com/jonasrosland),
[Thompson, C.](https://github.com/carlisia),
[Batard, T.](https://github.com/tbatard) (2020, September 16).
_vmware-tanzu/velero_. GitHub. Retrieved February 2, 2021 from
[https://github.com/vmware-tanzu/velero/blob/1fd49f4fd66ecf6cd959ce258efbd9a549d8902b/site/config.yaml](https://github.com/vmware-tanzu/velero/blob/1fd49f4fd66ecf6cd959ce258efbd9a549d8902b/site/config.yaml)
<a name="footnote4">4</a>: [Pursley, B.](https://github.com/brianpursley),
[Horgan, C.](https://github.com/celestehorgan), Takahashi, S. (2020, July 21).
_kubernetes/website_. GitHub. Retrieved February 2, 2021 from
[https://github.com/kubernetes/website/blob/072d4b41b45f5311538c24d375432a755f9e3f4c/layouts/partials/navbar-version-selector.html](https://github.com/kubernetes/website/blob/072d4b41b45f5311538c24d375432a755f9e3f4c/layouts/partials/navbar-version-selector.html)
[^4]:
[Pursley, B.](https://github.com/brianpursley),
[Horgan, C.](https://github.com/celestehorgan), Takahashi, S. (2020, July
21). _kubernetes/website_. GitHub. Retrieved February 2, 2021 from
[https://github.com/kubernetes/website/blob/072d4b41b45f5311538c24d375432a755f9e3f4c/layouts/partials/navbar-version-selector.html](https://github.com/kubernetes/website/blob/072d4b41b45f5311538c24d375432a755f9e3f4c/layouts/partials/navbar-version-selector.html)
---