chore: narrow PR scope to site docs updates

Agent-Logs-Url: https://github.com/velero-io/velero/sessions/3fa04f71-b7a9-47d5-b881-fb3cd9226d98 Co-authored-by: blackpiglet <59276555+blackpiglet@users.noreply.github.com>
2026-07-19 22:42:44 +00:00 · 2026-05-25 05:35:00 +00:00
parent fb603765e2
commit a34a676fa3
713 changed files with 2900 additions and 2900 deletions
@@ -40,7 +40,7 @@ Please provide the output of the following commands (Pasting long output into a

 **Vote on this issue!**

-This is an invitation to the Velero community to vote on issues, you can see the project's [top voted issues listed here](https://github.com/velero-io/velero/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).  
+This is an invitation to the Velero community to vote on issues, you can see the project's [top voted issues listed here](https://github.com/vmware-tanzu/velero/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).  
 Use the "reaction smiley face" up to the right of this comment to vote.

 - :+1: for "I would like to see this bug fixed as soon as possible"
@@ -1,5 +1,5 @@
 blank_issues_enabled: false
 contact_links:
  - name: Velero Q&A
-    url: https://github.com/velero-io/velero/discussions/categories/community-support-q-a 
+    url: https://github.com/vmware-tanzu/velero/discussions/categories/community-support-q-a 
    about: Have questions about Velero? Please ask them here.
@@ -26,7 +26,7 @@ about: Suggest an idea for this project

 **Vote on this issue!**

-This is an invitation to the Velero community to vote on issues, you can see the project's [top voted issues listed here](https://github.com/velero-io/velero/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).  
+This is an invitation to the Velero community to vote on issues, you can see the project's [top voted issues listed here](https://github.com/vmware-tanzu/velero/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).  
 Use the "reaction smiley face" up to the right of this comment to vote.

 - :+1: for "The project would be better with this feature added"
@@ -60,6 +60,6 @@ debug.test*
 .cache/

 # Go telemetry directory created when container sets HOME to working directory
-# This happens because Makefile uses 'docker run -w /github.com/velero-io/velero'
+# This happens because Makefile uses 'docker run -w /github.com/vmware-tanzu/velero'
 # and Go's os.UserConfigDir() falls back to $HOME/.config when XDG_CONFIG_HOME is unset
 .config/
@@ -423,7 +423,7 @@ formatters:
      simplify: true
    goimports:
      local-prefixes:
-        - github.com/velero-io/velero
+        - github.com/vmware-tanzu/velero

 severity:
  default: error
@@ -44,7 +44,7 @@ builds:
      - goos: windows
        goarch: s390x
    ldflags:
-      - -X "github.com/velero-io/velero/pkg/buildinfo.Version={{ .Tag }}" -X "github.com/velero-io/velero/pkg/buildinfo.GitSHA={{ .FullCommit }}" -X "github.com/velero-io/velero/pkg/buildinfo.GitTreeState={{ .Env.GIT_TREE_STATE }}" -X "github.com/velero-io/velero/pkg/buildinfo.ImageRegistry={{ .Env.REGISTRY }}"
+      - -X "github.com/vmware-tanzu/velero/pkg/buildinfo.Version={{ .Tag }}" -X "github.com/vmware-tanzu/velero/pkg/buildinfo.GitSHA={{ .FullCommit }}" -X "github.com/vmware-tanzu/velero/pkg/buildinfo.GitTreeState={{ .Env.GIT_TREE_STATE }}" -X "github.com/vmware-tanzu/velero/pkg/buildinfo.ImageRegistry={{ .Env.REGISTRY }}"
 archives:
  - name_template: "{{ .ProjectName }}-{{ .Tag }}-{{ .Os }}-{{ .Arch }}"
    wrap_in_directory: true
@@ -82,8 +82,8 @@ If you would like to add your logo to a future `Adopters of Velero` section on [

 [1]: #adding-a-logo-to-veleroio
 [2]: https://velero.io
-[3]: https://github.com/velero-io/velero/pulls
-[4]: https://github.com/velero-io/velero/pull/2242
+[3]: https://github.com/vmware-tanzu/velero/pulls
+[4]: https://github.com/vmware-tanzu/velero/pull/2242

 [10]: https://www.nirmata.com/2019/08/14/kubernetes-disaster-recovery-using-velero-and-nirmata/
 [11]: https://nirmata.com
@@ -28,29 +28,29 @@
  * [CHANGELOG-0.3.md][1]


-[25]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.15.md
-[24]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.14.md
-[23]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.13.md
-[22]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.12.md
-[21]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.11.md
-[20]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.10.md
-[19]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.9.md
-[18]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.8.md
-[17]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.7.md
-[16]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.6.md
-[15]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.5.md
-[14]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.4.md
-[13]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.3.md
-[12]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.2.md
-[11]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.1.md
-[10]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-1.0.md
-[9]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.11.md
-[8]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.10.md
-[7]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.9.md
-[6]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.8.md
-[5]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.7.md
-[4]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.6.md
-[3]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.5.md
-[2]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.4.md
-[1]: https://github.com/velero-io/velero/blob/main/changelogs/CHANGELOG-0.3.md
-[0]: https://github.com/velero-io/velero/blob/main/changelogs/unreleased
+[25]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.15.md
+[24]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.14.md
+[23]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.13.md
+[22]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.12.md
+[21]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.11.md
+[20]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.10.md
+[19]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.9.md
+[18]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.8.md
+[17]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.7.md
+[16]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.6.md
+[15]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.5.md
+[14]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.4.md
+[13]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.3.md
+[12]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.2.md
+[11]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.1.md
+[10]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-1.0.md
+[9]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.11.md
+[8]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.10.md
+[7]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.9.md
+[6]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.8.md
+[5]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.7.md
+[4]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.6.md
+[3]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.5.md
+[2]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.4.md
+[1]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/CHANGELOG-0.3.md
+[0]: https://github.com/vmware-tanzu/velero/blob/main/changelogs/unreleased
@@ -34,9 +34,9 @@ ENV CGO_ENABLED=0 \
    GOARM=${TARGETVARIANT} \
    LDFLAGS="-X ${PKG}/pkg/buildinfo.Version=${VERSION} -X ${PKG}/pkg/buildinfo.GitSHA=${GIT_SHA} -X ${PKG}/pkg/buildinfo.GitTreeState=${GIT_TREE_STATE} -X ${PKG}/pkg/buildinfo.ImageRegistry=${REGISTRY}"

-WORKDIR /go/src/github.com/velero-io/velero
+WORKDIR /go/src/github.com/vmware-tanzu/velero

-COPY . /go/src/github.com/velero-io/velero
+COPY . /go/src/github.com/vmware-tanzu/velero

 RUN mkdir -p /output/usr/bin && \
    export GOARM=$( echo "${GOARM}" | cut -c2-) && \
@@ -36,9 +36,9 @@ ENV CGO_ENABLED=0 \
    GOARM=${TARGETVARIANT} \
    LDFLAGS="-X ${PKG}/pkg/buildinfo.Version=${VERSION} -X ${PKG}/pkg/buildinfo.GitSHA=${GIT_SHA} -X ${PKG}/pkg/buildinfo.GitTreeState=${GIT_TREE_STATE} -X ${PKG}/pkg/buildinfo.ImageRegistry=${REGISTRY}"

-WORKDIR /go/src/github.com/velero-io/velero
+WORKDIR /go/src/github.com/vmware-tanzu/velero

-COPY . /go/src/github.com/velero-io/velero
+COPY . /go/src/github.com/vmware-tanzu/velero

 RUN mkdir -p /output/usr/bin && \
    export GOARM=$( echo "${GOARM}" | cut -c2-) && \
@@ -10,14 +10,14 @@ This document defines the project governance for Velero.

 The following code repositories are governed by Velero community and maintained under the `vmware-tanzu\Velero` organization.

-* **[Velero](https://github.com/velero-io/velero):** Main Velero codebase
+* **[Velero](https://github.com/vmware-tanzu/velero):** Main Velero codebase
 * **[Helm Chart](https://github.com/vmware-tanzu/helm-charts/tree/main/charts/velero):** The Helm chart for the Velero server component
-* **[Velero CSI Plugin](https://github.com/velero-io/velero-plugin-for-csi):** This repository contains Velero plugins for snapshotting CSI backed PVCs using the CSI beta snapshot APIs
-* **[Velero Plugin for vSphere](https://github.com/velero-io/velero-plugin-for-vsphere):** This repository contains the Velero Plugin for vSphere. This plugin is a volume snapshotter plugin that provides crash-consistent snapshots of vSphere block volumes and backup of volume data into S3 compatible storage.
-* **[Velero Plugin for AWS](https://github.com/velero-io/velero-plugin-for-aws):** This repository contains the plugins to support running Velero on AWS, including the object store plugin and the volume snapshotter plugin
-* **[Velero Plugin for GCP](https://github.com/velero-io/velero-plugin-for-gcp):** This repository contains the plugins to support running Velero on GCP, including the object store plugin and the volume snapshotter plugin
-* **[Velero Plugin for Azure](https://github.com/velero-io/velero-plugin-for-microsoft-azure):** This repository contains the plugins to support running Velero on Azure, including the object store plugin and the volume snapshotter plugin
-* **[Velero Plugin Example](https://github.com/velero-io/velero-plugin-example):** This repository contains example plugins for Velero
+* **[Velero CSI Plugin](https://github.com/vmware-tanzu/velero-plugin-for-csi):** This repository contains Velero plugins for snapshotting CSI backed PVCs using the CSI beta snapshot APIs
+* **[Velero Plugin for vSphere](https://github.com/vmware-tanzu/velero-plugin-for-vsphere):** This repository contains the Velero Plugin for vSphere. This plugin is a volume snapshotter plugin that provides crash-consistent snapshots of vSphere block volumes and backup of volume data into S3 compatible storage.
+* **[Velero Plugin for AWS](https://github.com/vmware-tanzu/velero-plugin-for-aws):** This repository contains the plugins to support running Velero on AWS, including the object store plugin and the volume snapshotter plugin
+* **[Velero Plugin for GCP](https://github.com/vmware-tanzu/velero-plugin-for-gcp):** This repository contains the plugins to support running Velero on GCP, including the object store plugin and the volume snapshotter plugin
+* **[Velero Plugin for Azure](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure):** This repository contains the plugins to support running Velero on Azure, including the object store plugin and the volume snapshotter plugin
+* **[Velero Plugin Example](https://github.com/vmware-tanzu/velero-plugin-example):** This repository contains example plugins for Velero


 ## Community Roles
@@ -67,12 +67,12 @@ interested in implementing the proposal should be either deeply engaged in the
 proposal process or be an author of the proposal.

 The proposal should be documented as a separated markdown file pushed to the root of the 
-`design` folder in the [Velero](https://github.com/velero-io/velero/tree/main/design)
+`design` folder in the [Velero](https://github.com/vmware-tanzu/velero/tree/main/design)
 repository via PR. The name of the file should follow the name pattern `<short
 meaningful words joined by '-'>_design.md`, e.g:
 `restore-hooks-design.md`.

-Use the [Proposal Template](https://github.com/velero-io/velero/blob/main/design/_template.md) as a starting point.
+Use the [Proposal Template](https://github.com/vmware-tanzu/velero/blob/main/design/_template.md) as a starting point.

 ### Proposal Lifecycle

@@ -88,7 +88,7 @@ To maintain velocity in a project as busy as Velero, the concept of [Lazy
 Consensus](http://en.osswiki.info/concepts/lazy_consensus) is practiced. Ideas
 and / or proposals should be shared by maintainers via
 GitHub with the appropriate maintainer groups (e.g.,
-`@velero-io/velero-maintainers`) tagged. Out of respect for other contributors,
+`@vmware-tanzu/velero-maintainers`) tagged. Out of respect for other contributors,
 major changes should also be accompanied by a ping on Slack or a note on the
 Velero mailing list as appropriate. Author(s) of proposal, Pull Requests,
 issues, etc.  will give a time period of no less than five (5) working days for
@@ -111,7 +111,7 @@ Lazy consensus does _not_ apply to the process of:

 ### Deprecation Process

-Any contributor may introduce a request to deprecate a feature or an option of a feature by opening a feature request issue in the velero-io/velero GitHub project. The issue should describe why the feature is no longer needed or has become detrimental to Velero, as well as whether and how it has been superseded. The submitter should give as much detail as possible.
+Any contributor may introduce a request to deprecate a feature or an option of a feature by opening a feature request issue in the vmware-tanzu/velero GitHub project. The issue should describe why the feature is no longer needed or has become detrimental to Velero, as well as whether and how it has been superseded. The submitter should give as much detail as possible.

 Once the issue is filed, a one-month discussion period begins. Discussions take place within the issue itself as well as in the community meetings. The person who opens the issue, or a maintainer, should add the date and time marking the end of the discussion period in a comment on the issue as soon as possible after it is opened. A decision on the issue needs to be made within this one-month period.

@@ -1,6 +1,6 @@
 # Velero Maintainers

-[GOVERNANCE.md](https://github.com/velero-io/velero/blob/main/GOVERNANCE.md) describes governance guidelines and maintainer responsibilities.
+[GOVERNANCE.md](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md) describes governance guidelines and maintainer responsibilities.

 ## Maintainers

@@ -18,7 +18,7 @@
 BIN ?= velero

 # This repo's root import path (under GOPATH).
-PKG := github.com/velero-io/velero
+PKG := github.com/vmware-tanzu/velero

 # Where to push the docker image.
 REGISTRY ?= velero
@@ -194,7 +194,7 @@ TTY := $(shell tty -s && echo "-t")

 # Example: make shell CMD="date > datefile"
 shell: build-dirs build-env
-	@# bind-mount the Velero root dir in at /github.com/velero-io/velero
+	@# bind-mount the Velero root dir in at /github.com/vmware-tanzu/velero
 	@# because the Kubernetes code-generator tools require the project to
 	@# exist in a directory hierarchy ending like this (but *NOT* necessarily
 	@# under $GOPATH).
@@ -204,7 +204,7 @@ shell: build-dirs build-env
 		-i $(TTY) \
 		--rm \
 		-u $$(id -u):$$(id -g) \
-		-v "$$(pwd):/github.com/velero-io/velero:delegated" \
+		-v "$$(pwd):/github.com/vmware-tanzu/velero:delegated" \
 		-v "$$(pwd)/_output/bin:/output:delegated" \
 		-v "$$(pwd)/.go/pkg:/go/pkg:delegated" \
 		-v "$$(pwd)/.go/std:/go/std:delegated" \
@@ -212,7 +212,7 @@ shell: build-dirs build-env
 		-v "$$(pwd)/.go/go-build:/.cache/go-build:delegated" \
 		-v "$$(pwd)/.go/golangci-lint:/.cache/golangci-lint:delegated" \
        -v "$$(pwd)/.go/goimports:/.cache/goimports:delegated" \
-		-w /github.com/velero-io/velero \
+		-w /github.com/vmware-tanzu/velero \
 		$(BUILDER_IMAGE) \
 		/bin/sh $(CMD)

@@ -432,7 +432,7 @@ changelog:
 #		PUBLISH=false \
 #		make release
 #
-# To run the release, which will publish a *DRAFT* GitHub release in github.com/velero-io/velero
+# To run the release, which will publish a *DRAFT* GitHub release in github.com/vmware-tanzu/velero
 # (you still need to review/publish the GitHub release manually):
 #		GITHUB_TOKEN=your-github-token \
 #		RELEASE_NOTES_FILE=changelogs/CHANGELOG-1.2.md \
@@ -1 +1 @@
-# Please go to the [Velero Wiki](https://github.com/velero-io/velero/wiki/) to see our latest roadmap, archived roadmaps and roadmap guidance.
+# Please go to the [Velero Wiki](https://github.com/vmware-tanzu/velero/wiki/) to see our latest roadmap, archived roadmaps and roadmap guidance.
@@ -5,7 +5,7 @@ Velero is an open source tool with a growing community devoted to safe backup an

 ## Supported Versions

-The Velero project maintains the following [governance document](https://github.com/velero-io/velero/blob/main/GOVERNANCE.md), [release document](https://github.com/velero-io/velero/blob/f42c63af1b9af445e38f78a7256b1c48ef79c10e/site/docs/main/release-instructions.md), and [support document](https://velero.io/docs/main/support-process/). Please refer to these for release and related details. Only the most recent version of Velero is supported. Each [release](https://github.com/velero-io/velero/releases) includes information about upgrading to the latest version.
+The Velero project maintains the following [governance document](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md), [release document](https://github.com/vmware-tanzu/velero/blob/f42c63af1b9af445e38f78a7256b1c48ef79c10e/site/docs/main/release-instructions.md), and [support document](https://velero.io/docs/main/support-process/). Please refer to these for release and related details. Only the most recent version of Velero is supported. Each [release](https://github.com/vmware-tanzu/velero/releases) includes information about upgrading to the latest version.


 ## Reporting a Vulnerability - Private Disclosure Process
@@ -18,7 +18,7 @@ If you know of a publicly disclosed security vulnerability for Velero, please **

 **IMPORTANT: Do not file public issues on GitHub for security vulnerabilities**

-To report a vulnerability or a security-related issue, please contact the email address with the details of the vulnerability. The email will be fielded by the Security Team and then shared with the Velero maintainers who have committer and release permissions. Emails will be addressed within 3 business days, including a detailed plan to investigate the issue and any potential workarounds to perform in the meantime. Do not report non-security-impacting bugs through this channel. Use [GitHub issues](https://github.com/velero-io/velero/issues/new/choose) instead.
+To report a vulnerability or a security-related issue, please contact the email address with the details of the vulnerability. The email will be fielded by the Security Team and then shared with the Velero maintainers who have committer and release permissions. Emails will be addressed within 3 business days, including a detailed plan to investigate the issue and any potential workarounds to perform in the meantime. Do not report non-security-impacting bugs through this channel. Use [GitHub issues](https://github.com/vmware-tanzu/velero/issues/new/choose) instead.


 ## Proposed Email Content
@@ -68,7 +68,7 @@ The Security Team will respond to vulnerability reports as follows:

 ## Public Disclosure Process

-The Security Team publishes a [public advisory](https://github.com/velero-io/velero/security/advisories) to the Velero community via GitHub. In most cases, additional communication via Slack, Twitter, mailing lists, blog and other channels will assist in educating Velero users and rolling out the patched release to affected users. 
+The Security Team publishes a [public advisory](https://github.com/vmware-tanzu/velero/security/advisories) to the Velero community via GitHub. In most cases, additional communication via Slack, Twitter, mailing lists, blog and other channels will assist in educating Velero users and rolling out the patched release to affected users. 

 The Security Team will also publish any mitigating steps users can take until the fix can be applied to their Velero instances. Velero distributors will handle creating and publishing their own security advisories.

@@ -69,8 +69,8 @@ carefully to ensure a successful upgrade!**
 - The `Config` CRD has been replaced by `BackupStorageLocation` and `VolumeSnapshotLocation` CRDs. 
 - The interface for external plugins (object/block stores, backup/restore item actions) has changed. If you have authored any custom plugins, they'll 
 need to be updated for v0.10.
-    - The [`ObjectStore.ListCommonPrefixes`](https://github.com/velero-io/velero/blob/main/pkg/cloudprovider/object_store.go#L50) signature has changed to add a `prefix` parameter.
-    - Registering plugins has changed. Create a new plugin server with the `NewServer` function, and register plugins with the appropriate functions. See the [`Server`](https://github.com/velero-io/velero/blob/main/pkg/plugin/server.go#L37) interface for details.
+    - The [`ObjectStore.ListCommonPrefixes`](https://github.com/vmware-tanzu/velero/blob/main/pkg/cloudprovider/object_store.go#L50) signature has changed to add a `prefix` parameter.
+    - Registering plugins has changed. Create a new plugin server with the `NewServer` function, and register plugins with the appropriate functions. See the [`Server`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/server.go#L37) interface for details.
 - The organization of Ark data in object storage has changed. Existing data will need to be moved around to conform to the new layout.

 ### All Changes
@@ -137,7 +137,7 @@
 ### Highlights:
  * Ark now has support for backing up and restoring Kubernetes volumes using a free open-source backup tool called [restic](https://github.com/restic/restic).
    This provides users an out-of-the-box solution for backing up and restoring almost any type of Kubernetes volume, whether or not it has snapshot support
-    integrated with Ark. For more information, see the [documentation](https://github.com/velero-io/velero/blob/main/docs/restic.md).
+    integrated with Ark. For more information, see the [documentation](https://github.com/vmware-tanzu/velero/blob/main/docs/restic.md).
  * Support for Prometheus metrics has been added! View total number of backup attempts (including success or failure), total backup size in bytes, and backup
    durations. More metrics coming in future releases!

@@ -2,7 +2,7 @@
 ### 2022-11-23

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.10.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.10.0

 ### Container Image
 `velero/velero:v1.10.0`
@@ -20,7 +20,7 @@ In this release, we introduced the Unified Repository architecture to build a da

 In this release, we also deeply integrate Velero with Kopia, specifically, Kopia's uploader modules are isolated as a generic file system uploader; Kopia's repository modules are encapsulated as the unified backup repository.

-For more information, refer to the [design document](https://github.com/velero-io/velero/blob/v1.10.0/design/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md).
+For more information, refer to the [design document](https://github.com/vmware-tanzu/velero/blob/v1.10.0/design/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md).

 #### File system backup refactor
 Velero's file system backup (a.k.s. pod volume backup or formerly restic backup) is refactored as the first user of the Unified Repository architecture. Specifically, we added a new path, the Kopia path, besides the existing Restic path. While Restic path is still available and set as default, you can opt in Kopia path by specifying the `uploader-type` parameter at installation time. Meanwhile, you are free to restore from existing backups under either path, Velero dynamically switches to the correct path to process the restore.
@@ -33,7 +33,7 @@ Meanwhile, we've created a performance guide for both Restic path and Kopia path

 #### Plugin versioning V1 refactor
 In this release, Velero moves plugins BackupItemAction, RestoreItemAction and VolumeSnapshotterAction to version v1, this allows future plugin changes that do not support backward compatibility, so is a preparation for various complex tasks, for example, data movement tasks.
-For more information, refer to the [plugin versioning design document](https://github.com/velero-io/velero/blob/v1.10.0/design/plugin-versioning.md).
+For more information, refer to the [plugin versioning design document](https://github.com/vmware-tanzu/velero/blob/v1.10.0/design/plugin-versioning.md).

 #### Refactor the controllers using Kubebuilder v3
 In this release we continued our code modernization work, rewriting some controllers using Kubebuilder v3. This work is ongoing and we will continue to make progress in future releases.
@@ -75,9 +75,9 @@ Due to file system backup refactor, below modules and parameters name have been
 Due to the major changes of file system backup, the old upgrade steps are not suitable any more. For the new upgrade steps, visit [v1.10 upgrade guide document](https://velero.io/docs/v1.10/upgrade-to-1.10/).

 #### Limitations/Known issues
-In this release, Kopia backup repository (so the Kopia path of file system backup) doesn't support self signed certificate for S3 compatible storage. To track this problem, refer to this [Velero issue](https://github.com/velero-io/velero/issues/5123) or [Kopia issue](https://github.com/kopia/kopia/issues/1443). 
+In this release, Kopia backup repository (so the Kopia path of file system backup) doesn't support self signed certificate for S3 compatible storage. To track this problem, refer to this [Velero issue](https://github.com/vmware-tanzu/velero/issues/5123) or [Kopia issue](https://github.com/kopia/kopia/issues/1443). 

-Due to the code change in Velero, there will be some code change required in vSphere plugin, without which the functionality may be impacted.  Therefore, if you are using vSphere plugin in your workflow, please hold the upgrade until the issue [#485](https://github.com/velero-io/velero-plugin-for-vsphere/issues/485) is fixed in vSphere plugin.
+Due to the code change in Velero, there will be some code change required in vSphere plugin, without which the functionality may be impacted.  Therefore, if you are using vSphere plugin in your workflow, please hold the upgrade until the issue [#485](https://github.com/vmware-tanzu/velero-plugin-for-vsphere/issues/485) is fixed in vSphere plugin.

 ### All changes
  
@@ -185,6 +185,6 @@ Related issue: #2413 (#5178, @allenxu404)
  * Delete opened issues triage action. (#5041, @jxun)
  * When spec.RestoreStatus is empty, don't restore status (#5008, @sseago)
  * Added DownloadTargetKindCSIBackupVolumeSnapshots for retrieving the signed URL to download only the `<backup name>`-csi-volumesnapshots.json.gz  and DownloadTargetKindCSIBackupVolumeSnapshotContents to download only `<backup name>`-csi-volumesnapshotcontents.json.gz in the DownloadRequest CR structure. These files are already present in the backup layout.  (#4980, @anshulahuja98)
-  * Refactor BackupItemAction proto and related code to backupitemaction/v1 package.  This is part of implementation of the plugin version design https://github.com/velero-io/velero/blob/main/design/plugin-versioning.md (#4943, @phuongatemc)
+  * Refactor BackupItemAction proto and related code to backupitemaction/v1 package.  This is part of implementation of the plugin version design https://github.com/vmware-tanzu/velero/blob/main/design/plugin-versioning.md (#4943, @phuongatemc)
  * Unified Repository Design (#4926, @Lyndon-Li)
  * Add credentials to volume snapshot locations (#4864, @sseago)
@@ -2,7 +2,7 @@
 ### 2023-04-07

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.11.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.11.0

 ### Container Image
 `velero/velero:v1.11.0`
@@ -26,10 +26,10 @@ This feature implemented the RestoreItemAction v2. RIA v2 has three new methods:
 The Progress() and Cancel() methods are needed to facilitate long-running RestoreItemAction plugin actions that may not be complete when the Execute() method returns. This will allow long-running RestoreItemAction plugin actions to continue in the background while the Velero moves to the following plugin or the next item. The AreAdditionalItemsReady() method is needed to allow plugins to tell Velero to wait until the returned additional items have been restored and are ready for use in the cluster before restoring the current item.

 #### Plugin Progress Monitoring
-This is intended as a replacement for the previously-approved Upload Progress Monitoring design ([Upload Progress Monitoring](https://github.com/velero-io/velero/blob/main/design/upload-progress.md)) to expand the supported use cases beyond snapshot upload to include what was previously called Async Backup/Restore Item Actions.
+This is intended as a replacement for the previously-approved Upload Progress Monitoring design ([Upload Progress Monitoring](https://github.com/vmware-tanzu/velero/blob/main/design/upload-progress.md)) to expand the supported use cases beyond snapshot upload to include what was previously called Async Backup/Restore Item Actions.

 #### Flexible resource policy that can filter volumes to skip in the backup
-This feature provides a flexible policy to filter volumes in the backup without requiring patching any labels or annotations to the pods or volumes. This policy is configured as k8s ConfigMap and maintained by the users themselves, and it can be extended to more scenarios in the future. By now, the policy rules out volumes from backup depending on the CSI driver, NFS setting, volume size, and StorageClass setting. Please refer to [policy API design](https://github.com/velero-io/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md#api-design) for the policy's ConifgMap format. It is not guaranteed to work on unofficial third-party plugins as it may not follow the existing backup workflow code logic of Velero.
+This feature provides a flexible policy to filter volumes in the backup without requiring patching any labels or annotations to the pods or volumes. This policy is configured as k8s ConfigMap and maintained by the users themselves, and it can be extended to more scenarios in the future. By now, the policy rules out volumes from backup depending on the CSI driver, NFS setting, volume size, and StorageClass setting. Please refer to [policy API design](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md#api-design) for the policy's ConifgMap format. It is not guaranteed to work on unofficial third-party plugins as it may not follow the existing backup workflow code logic of Velero.

 #### Resource Filters that can distinguish cluster scope and namespace scope resources
 This feature adds four new resource filters for backup. The new filters are separated into cluster scope and namespace scope. Before this feature, Velero could not filter cluster scope resources precisely. This feature provides the ability and refactors existing resource filter parameters.
@@ -2,7 +2,7 @@
 ### 2023-08-18

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.12.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.12.0

 ### Container Image
 `velero/velero:v1.12.0`
@@ -23,17 +23,17 @@ CSI Snapshot Data Movement is useful in below scenarios:
 * For on-premises users, the storage usually doesn't support durable snapshots, so it is impossible/less efficient/cost ineffective to keep volume snapshots by the storage This feature helps to move the snapshot data to a storage with lower cost and larger scale for long time preservation.
 * For public cloud users, this feature helps users to fulfill the multiple cloud strategy. It allows users to back up volume snapshots from one cloud provider and preserve or restore the data to another cloud provider. Then users will be free to flow their business data across cloud providers based on Velero backup and restore

-CSI Snapshot Data Movement is built according to the Volume Snapshot Data Movement design ([Volume Snapshot Data Movement](https://github.com/velero-io/velero/blob/main/design/Implemented/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md)). More details can be found in the design.
+CSI Snapshot Data Movement is built according to the Volume Snapshot Data Movement design ([Volume Snapshot Data Movement](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md)). More details can be found in the design.

 #### Resource Modifiers
 In many use cases, customers often need to substitute specific values in Kubernetes resources during the restoration process like changing the namespace, changing the storage class, etc. 

-To address this need, Resource Modifiers (also known as JSON Substitutions) offer a generic solution in the restore workflow. It allows the user to define filters for specific resources and then specify a JSON patch (operator, path, value) to apply to the resource. This feature simplifies the process of making substitutions without requiring the implementation of a new RestoreItemAction plugin. More details can be found in Volume Snapshot Resource Modifiers design ([Resource Modifiers](https://github.com/velero-io/velero/blob/main/design/Implemented/json-substitution-action-design.md)).
+To address this need, Resource Modifiers (also known as JSON Substitutions) offer a generic solution in the restore workflow. It allows the user to define filters for specific resources and then specify a JSON patch (operator, path, value) to apply to the resource. This feature simplifies the process of making substitutions without requiring the implementation of a new RestoreItemAction plugin. More details can be found in Volume Snapshot Resource Modifiers design ([Resource Modifiers](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/json-substitution-action-design.md)).

 #### Multiple VolumeSnapshotClasses
 Prior to version 1.12, the Velero CSI plugin would choose the VolumeSnapshotClass in the cluster based on matching driver names and the presence of the "velero.io/csi-volumesnapshot-class" label. However,  this approach proved inadequate for many user scenarios.

-With the introduction of version 1.12, Velero now offers support for multiple VolumeSnapshotClasses in the CSI Plugin, enabling users to select a specific class for a particular backup. More details can be found in Multiple VolumeSnapshotClasses design ([Multiple VolumeSnapshotClasses](https://github.com/velero-io/velero/blob/main/design/Implemented/multiple-csi-volumesnapshotclass-support.md)).
+With the introduction of version 1.12, Velero now offers support for multiple VolumeSnapshotClasses in the CSI Plugin, enabling users to select a specific class for a particular backup. More details can be found in Multiple VolumeSnapshotClasses design ([Multiple VolumeSnapshotClasses](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/multiple-csi-volumesnapshotclass-support.md)).

 #### Restore Finalizer
 Before v1.12, the restore controller would only delete restore resources but wouldn’t delete restore data from the backup storage location when the command `velero restore delete` was executed. The only chance Velero deletes restores data from the backup storage location is when the associated backup is deleted.
@@ -2,7 +2,7 @@
 ### 2024-01-10

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.13.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.13.0

 ### Container Image
 `velero/velero:v1.13.0`
@@ -16,7 +16,7 @@ https://velero.io/docs/v1.13/upgrade-to-1.13/
 ### Highlights

 #### Resource Modifier Enhancement
-Velero introduced the Resource Modifiers in v1.12.0. This feature allows users to specify a ConfigMap with a set of rules to modify the resources during restoration. However, only the JSON Patch is supported when creating the rules, and JSON Patch has some limitations, which cannot cover all use cases. In v1.13.0, Velero adds new support for JSON Merge Patch and Strategic Merge Patch, which provide more power and flexibility and allow users to use the same ConfigMap to apply patches on the resources. More design details can be found in [Support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers](https://github.com/velero-io/velero/blob/main/design/Implemented/merge-patch-and-strategic-in-resource-modifier.md) design. For instructions on how to use the feature, please refer to the [Resource Modifiers](https://velero.io/docs/v1.13/restore-resource-modifiers/) doc.
+Velero introduced the Resource Modifiers in v1.12.0. This feature allows users to specify a ConfigMap with a set of rules to modify the resources during restoration. However, only the JSON Patch is supported when creating the rules, and JSON Patch has some limitations, which cannot cover all use cases. In v1.13.0, Velero adds new support for JSON Merge Patch and Strategic Merge Patch, which provide more power and flexibility and allow users to use the same ConfigMap to apply patches on the resources. More design details can be found in [Support JSON Merge Patch and Strategic Merge Patch in Resource Modifiers](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/merge-patch-and-strategic-in-resource-modifier.md) design. For instructions on how to use the feature, please refer to the [Resource Modifiers](https://velero.io/docs/v1.13/restore-resource-modifiers/) doc.

 #### Node-Agent Concurrency
 Velero data movement activities from fs-backups and CSI snapshot data movements run in Velero node-agent, so may be hosted by every node in the cluster and consume resources (i.e. CPU, memory, network bandwidth) from there. With v1.13, users are allowed to configure how many data movement activities (a.k.a, loads) run in each node globally or by node, so that users can better leverage the performance of Velero data movement activities and the resource consumption in the cluster. For more information, check the [Node-Agent Concurrency](https://velero.io/docs/v1.13/node-agent-concurrency/) document. 
@@ -57,8 +57,8 @@ To fix CVEs and keep pace with Golang, Velero made changes as follows:

 ### Breaking changes
 * Backup describe command: due to the backup describe output enhancement, some existing information (i.e. the output for native snapshot, CSI snapshot, and fs-backup) has been moved to the Backup Volumes section with some format changes.
-* API type changes: changes the field [DataMoverConfig](https://github.com/velero-io/velero/blob/v1.13.0/pkg/apis/velero/v2alpha1/data_upload_types.go#L54) in DataUploadSpec from `*map[string][string]`` to `map[string]string`
-* Velero install command: due to the issue [#7264](https://github.com/velero-io/velero/issues/7264), v1.13.0 introduces a break change that make the informer cache enabled by default to keep the actual behavior consistent with the helper message(the informer cache is disabled by default before the change).
+* API type changes: changes the field [DataMoverConfig](https://github.com/vmware-tanzu/velero/blob/v1.13.0/pkg/apis/velero/v2alpha1/data_upload_types.go#L54) in DataUploadSpec from `*map[string][string]`` to `map[string]string`
+* Velero install command: due to the issue [#7264](https://github.com/vmware-tanzu/velero/issues/7264), v1.13.0 introduces a break change that make the informer cache enabled by default to keep the actual behavior consistent with the helper message(the informer cache is disabled by default before the change).


 ### Limitations/Known issues
@@ -1,7 +1,7 @@
 ## v1.14

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.14.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.14.0

 ### Container Image
 `velero/velero:v1.14.0`
@@ -1,7 +1,7 @@
 ## v1.15

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.15.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.15.0

 ### Container Image
 `velero/velero:v1.15.0`
@@ -19,13 +19,13 @@ Data transfer activities for CSI Snapshot Data Movement are moved from node-agen
 - This enables users to to control resource (i.e., cpu, memory) allocations in a granular manner, e.g., control them per backup/restore of a volume.
 - This enhances the resilience, crash of one data movement activity won't affect others.
 - This prevents unnecessary full backup because of host path changes after workload pods restart.
- For more information, check the design https://github.com/velero-io/velero/blob/main/design/Implemented/vgdp-micro-service/vgdp-micro-service.md.
+- For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/vgdp-micro-service/vgdp-micro-service.md.

 #### Item Block concepts and ItemBlockAction (IBA) plugin
 Item Block concepts are introduced for resource backups to help to achieve multiple thread backups. Specifically, correlated resources are categorized in the same item block and item blocks could be processed concurrently in multiple threads.  
 ItemBlockAction plugin is introduced to help Velero to categorize resources into item blocks. At present, Velero provides built-in IBAs for pods and PVCs and Velero also supports customized IBAs for any resources.  
 In v1.15, Velero doesn't support multiple thread process of item blocks though item block concepts and IBA plugins are fully supported. The multiple thread support will be delivered in future releases.  
-For more information, check the design https://github.com/velero-io/velero/blob/main/design/backup-performance-improvements.md.  
+For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/backup-performance-improvements.md.  

 #### Node selection for repository maintenance job
 Repository maintenance are resource consuming tasks, Velero now allows you to configure the nodes to run repository maintenance jobs, so that you can run repository maintenance jobs in idle nodes or avoid them to run in nodes hosting critical workloads.  
@@ -50,9 +50,9 @@ For more information, check the document https://velero.io/docs/v1.15/backup-rep

 #### Performance improvements
 In 1.15, several performance related issues/enhancements are included, which makes significant performance improvements in specific scenarios:  
- There was a memory leak of Velero server after plugin calls, now it is fixed, see issue https://github.com/velero-io/velero/issues/7925
- The `client-burst/client-qps` parameters are automatically inherited to plugins, so that you can use the same velero server parameters to accelerate the plugin executions when large number of API server calls happen, see issue https://github.com/velero-io/velero/issues/7806
- Maintenance of Kopia repository takes huge memory in scenarios that huge number of files have been backed up, Velero 1.15 has included the Kopia upstream enhancement to fix the problem, see issue https://github.com/velero-io/velero/issues/7510
+- There was a memory leak of Velero server after plugin calls, now it is fixed, see issue https://github.com/vmware-tanzu/velero/issues/7925
+- The `client-burst/client-qps` parameters are automatically inherited to plugins, so that you can use the same velero server parameters to accelerate the plugin executions when large number of API server calls happen, see issue https://github.com/vmware-tanzu/velero/issues/7806
+- Maintenance of Kopia repository takes huge memory in scenarios that huge number of files have been backed up, Velero 1.15 has included the Kopia upstream enhancement to fix the problem, see issue https://github.com/vmware-tanzu/velero/issues/7510

 ### Runtime and dependencies
 Golang runtime: v1.22.8  
@@ -65,7 +65,7 @@ Therefore, a user option is added in the same backup PVC configuration configMap

 ### Breaking changes
 #### Deprecation of Restic
-Restic path for fs-backup is in deprecation process starting from 1.15. According to [Velero deprecation policy](https://github.com/velero-io/velero/blob/v1.15/GOVERNANCE.md#deprecation-policy), for 1.15, if Restic path is used the backup/restore of fs-backup still creates and succeeds, but you will see warnings in below scenarios:  
+Restic path for fs-backup is in deprecation process starting from 1.15. According to [Velero deprecation policy](https://github.com/vmware-tanzu/velero/blob/v1.15/GOVERNANCE.md#deprecation-policy), for 1.15, if Restic path is used the backup/restore of fs-backup still creates and succeeds, but you will see warnings in below scenarios:  
 - When `--uploader-type=restic` is used in Velero installation
 - When Restic path is used to create backup/restore of fs-backup

@@ -83,7 +83,7 @@ In 1.15, below Velero server parameters for repository maintenance jobs are move
 ```

 #### Changing PVC selected-node feature is deprecated
-In 1.15, the [Changing PVC selected-node feature](https://velero.io/docs/v1.15/restore-reference/#changing-pvc-selected-node) enters deprecation process and will be removed in future releases according to [Velero deprecation policy](https://github.com/velero-io/velero/blob/v1.15/GOVERNANCE.md#deprecation-policy). Usage of this feature for any purpose is not recommended.  
+In 1.15, the [Changing PVC selected-node feature](https://velero.io/docs/v1.15/restore-reference/#changing-pvc-selected-node) enters deprecation process and will be removed in future releases according to [Velero deprecation policy](https://github.com/vmware-tanzu/velero/blob/v1.15/GOVERNANCE.md#deprecation-policy). Usage of this feature for any purpose is not recommended.  

 ### All Changes
  * add no-relabeling option to backupPVC configmap (#8288, @sseago)
@@ -1,7 +1,7 @@
 ## v1.16

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.16.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.16.0

 ### Container Image
 `velero/velero:v1.16.0`
@@ -15,28 +15,28 @@ https://velero.io/docs/v1.16/upgrade-to-1.16/
 ### Highlights
 #### Windows cluster support
 In v1.16, Velero supports to run in Windows clusters and backup/restore Windows workloads, either stateful or stateless:
- * Hybrid build and all-in-one image: the build process is enhanced to build an all-in-one image for hybrid CPU architecture and hybrid platform. For more information, check the design https://github.com/velero-io/velero/blob/main/design/multiple-arch-build-with-windows.md
+ * Hybrid build and all-in-one image: the build process is enhanced to build an all-in-one image for hybrid CPU architecture and hybrid platform. For more information, check the design https://github.com/vmware-tanzu/velero/blob/main/design/multiple-arch-build-with-windows.md
 * Deployment in Windows clusters: Velero node-agent, data mover pods and maintenance jobs now support to run in both linux and Windows nodes
 * Data mover backup/restore Windows workloads: Velero built-in data mover supports Windows workloads throughout its full cycle, i.e., discovery, backup, restore, pre/post hook, etc. It automatically identifies Windows workloads and schedules data mover pods to the right group of nodes

-Check the epic issue https://github.com/velero-io/velero/issues/8289 for more information.  
+Check the epic issue https://github.com/vmware-tanzu/velero/issues/8289 for more information.  

 #### Parallel Item Block backup
 v1.16 now supports to back up item blocks in parallel. Specifically, during backup, correlated resources are grouped in item blocks and Velero backup engine creates a thread pool to back up the item blocks in parallel. This significantly improves the backup throughput, especially when there are large scale of resources.  
 Pre/post hooks also belongs to item blocks, so will also run in parallel along with the item blocks.  
 Users are allowed to configure the parallelism through the `--item-block-worker-count` Velero server parameter. If not configured, the default parallelism is 1.  

-For more information, check issue https://github.com/velero-io/velero/issues/8334.  
+For more information, check issue https://github.com/vmware-tanzu/velero/issues/8334.  

 #### Data mover restore enhancement in scalability
-In previous releases, for each volume of WaitForFirstConsumer mode, data mover restore is only allowed to happen in the node that the volume is attached. This severely degrades the parallelism and the balance of node resource(CPU, memory, network bandwidth) consumption for data mover restore (https://github.com/velero-io/velero/issues/8044).  
+In previous releases, for each volume of WaitForFirstConsumer mode, data mover restore is only allowed to happen in the node that the volume is attached. This severely degrades the parallelism and the balance of node resource(CPU, memory, network bandwidth) consumption for data mover restore (https://github.com/vmware-tanzu/velero/issues/8044).  

-In v1.16, users are allowed to configure data mover restores running and spreading evenly across all nodes in the cluster. The configuration is done through a new flag `ignoreDelayBinding` in node-agent configuration (https://github.com/velero-io/velero/issues/8242).  
+In v1.16, users are allowed to configure data mover restores running and spreading evenly across all nodes in the cluster. The configuration is done through a new flag `ignoreDelayBinding` in node-agent configuration (https://github.com/vmware-tanzu/velero/issues/8242).  

 #### Data mover enhancements in observability 
 In 1.16, some observability enhancements are added:
- * Output various statuses of intermediate objects for failures of data mover backup/restore (https://github.com/velero-io/velero/issues/8267)
- * Output the errors when Velero fails to delete intermediate objects during clean up (https://github.com/velero-io/velero/issues/8125)
+ * Output various statuses of intermediate objects for failures of data mover backup/restore (https://github.com/vmware-tanzu/velero/issues/8267)
+ * Output the errors when Velero fails to delete intermediate objects during clean up (https://github.com/vmware-tanzu/velero/issues/8125)

 The outputs are in the same node-agent log and enabled automatically.  

@@ -45,24 +45,24 @@ In previous releases, a unnecessary VolumeSnapshotContent object is retained for

 In 1.16, the retained VolumeSnapshotContent is removed from the backup, so no unnecessary CSI objects are synced or restored.  

-For more information, check issue https://github.com/velero-io/velero/issues/8725.  
+For more information, check issue https://github.com/vmware-tanzu/velero/issues/8725.  

 #### Backup Repository Maintenance enhancement in resiliency and observability
 In v1.16, some enhancements of backup repository maintenance are added to improve the observability and resiliency:
- * A new backup repository maintenance history section, called `RecentMaintenance`, is added to the BackupRepository CR. Specifically, for each BackupRepository, including start/completion time, completion status and error message. (https://github.com/velero-io/velero/issues/7810)
- * Running maintenance jobs are now recaptured after Velero server restarts. (https://github.com/velero-io/velero/issues/7753)
- * The maintenance job will not be launched for readOnly BackupStorageLocation. (https://github.com/velero-io/velero/issues/8238)
- * The backup repository will not try to initialize a new repository for readOnly BackupStorageLocation. (https://github.com/velero-io/velero/issues/8091)
- * Users now are allowed to configure the intervals of an effective maintenance in the way of `normalGC`, `fastGC` and `eagerGC`, through the `fullMaintenanceInterval` parameter in backupRepository configuration. (https://github.com/velero-io/velero/issues/8364)
+ * A new backup repository maintenance history section, called `RecentMaintenance`, is added to the BackupRepository CR. Specifically, for each BackupRepository, including start/completion time, completion status and error message. (https://github.com/vmware-tanzu/velero/issues/7810)
+ * Running maintenance jobs are now recaptured after Velero server restarts. (https://github.com/vmware-tanzu/velero/issues/7753)
+ * The maintenance job will not be launched for readOnly BackupStorageLocation. (https://github.com/vmware-tanzu/velero/issues/8238)
+ * The backup repository will not try to initialize a new repository for readOnly BackupStorageLocation. (https://github.com/vmware-tanzu/velero/issues/8091)
+ * Users now are allowed to configure the intervals of an effective maintenance in the way of `normalGC`, `fastGC` and `eagerGC`, through the `fullMaintenanceInterval` parameter in backupRepository configuration. (https://github.com/vmware-tanzu/velero/issues/8364)

 #### Volume Policy enhancement of filtering volumes by PVC labels
-In v1.16, Volume Policy is extended to support filtering volumes by PVC labels. (https://github.com/velero-io/velero/issues/8256).   
+In v1.16, Volume Policy is extended to support filtering volumes by PVC labels. (https://github.com/vmware-tanzu/velero/issues/8256).   

 #### Resource Status restore per object
-In v1.16, users are allowed to define whether to restore resource status per object through an annotation `velero.io/restore-status` set on the object. (https://github.com/velero-io/velero/issues/8204).  
+In v1.16, users are allowed to define whether to restore resource status per object through an annotation `velero.io/restore-status` set on the object. (https://github.com/vmware-tanzu/velero/issues/8204).  

 #### Velero Restore Helper binary is merged into Velero image 
-In v1.16, Velero banaries, i.e., velero, velero-helper and velero-restore-helper, are all included into the single Velero image. (https://github.com/velero-io/velero/issues/8484).  
+In v1.16, Velero banaries, i.e., velero, velero-helper and velero-restore-helper, are all included into the single Velero image. (https://github.com/vmware-tanzu/velero/issues/8484).  

 ### Runtime and dependencies
 Golang runtime: 1.23.7  
@@ -1,7 +1,7 @@
 ## v1.17

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.17.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.17.0

 ### Container Image
 `velero/velero:v1.17.0`
@@ -19,11 +19,11 @@ In v1.17, Velero fs-backup is modernized to the micro-service architecture, whic
 - fs-backup is more robust, the running backup/restore could survive from node-agent restart; and the resource allocation is in a more granular manner, the failure of one backup/restore won't impact others.  
 - The resource usage of node-agent is steady, especially, the node-agent pods won't request huge memory and hold it for a long time.  

-Check design https://github.com/velero-io/velero/blob/main/design/vgdp-micro-service-for-fs-backup/vgdp-micro-service-for-fs-backup.md for more details.  
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/vgdp-micro-service-for-fs-backup/vgdp-micro-service-for-fs-backup.md for more details.  

 #### fs-backup support Windows cluster
 In v1.17, Velero fs-backup supports to backup/restore Windows workloads. By leveraging the new micro-service architecture for fs-backup, data mover pods could run in Windows nodes and backup/restore Windows volumes. Together with CSI snapshot data movement for Windows which is delivered in 1.16, Velero now supports Windows workload backup/restore in full scenarios.  
-Check design https://github.com/velero-io/velero/blob/main/design/vgdp-micro-service-for-fs-backup/vgdp-micro-service-for-fs-backup.md for more details.  
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/vgdp-micro-service-for-fs-backup/vgdp-micro-service-for-fs-backup.md for more details.  

 #### Volume group snapshot support
 In v1.17, Velero supports [volume group snapshots](https://kubernetes.io/blog/2024/12/18/kubernetes-1-32-volume-group-snapshot-beta/) which is a beta feature in Kubernetes upstream, for both CSI snapshot backup and CSI snapshot data movement. This allows a snapshot to be taken from multiple volumes at the same point-in-time to achieve write order consistency, which is helpful to achieve better data consistency when multiple volumes being backed up are correlated.  
@@ -31,20 +31,20 @@ Check the document https://velero.io/docs/main/volume-group-snapshots/ for more

 #### Priority class support
 In v1.17, [Kubernetes priority class](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass) is supported for all modules across Velero. Specifically, users are allowed to configure priority class to Velero server, node-agent, data mover pods, backup repository maintenance jobs separately.  
-Check design https://github.com/velero-io/velero/blob/main/design/Implemented/priority-class-name-support_design.md for more details.  
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/priority-class-name-support_design.md for more details.  

 #### Scalability and Resiliency improvements of data movers
 ##### Reduce excessive number of data mover pods in Pending state
 In v1.17, Velero allows users to set a `PrepareQueueLength` in the node-agent configuration, data mover pods and volumes out of this number won't be created until data path quota is available, so that excessive number cluster resources won't  be taken unnecessarily, which is particularly helpful for large scale environments. This improvement applies to all kinds of data movements, including fs-backup and CSI snapshot data movement.  
-Check design https://github.com/velero-io/velero/blob/main/design/node-agent-load-soothing.md for more details.  
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/node-agent-load-soothing.md for more details.  

 ##### Enhancement on node-agent restart handling for data movements
 In v1.17, data movements in all phases could survive from node-agent restart and resume themselves; when a data movement gets orphaned in special cases, e.g., cluster node absent, it could also be canceled appropriately after the restart. This improvement applies to all kinds of data movements, including fs-backup and CSI snapshot data movement.  
-Check issue https://github.com/velero-io/velero/issues/8534 for more details.  
+Check issue https://github.com/vmware-tanzu/velero/issues/8534 for more details.  

 ##### CSI snapshot data movement restore node-selection and node-selection by storage class
 In v1.17, CSI snapshot data movement restore acquires the same node-selection capability as backup, that is, users could specify which nodes can/cannot run data mover pods for both backup and restore now. And users are also allowed to configure the node-selection per storage class, which is particularly helpful to the environments where a storage class are not usable by all cluster nodes.  
-Check issue https://github.com/velero-io/velero/issues/8186 and https://github.com/velero-io/velero/issues/8223 for more details.  
+Check issue https://github.com/vmware-tanzu/velero/issues/8186 and https://github.com/vmware-tanzu/velero/issues/8223 for more details.  

 #### Include/exclude policy support for resource policy
 In v1.17, Velero resource policy supports `includeExcludePolicy` besides the existing `volumePolicy`. This allows users to set include/exclude filters for resources in a resource policy configmap, so that these filters are reusable among multiple backups.  
@@ -58,7 +58,7 @@ kopia: 0.21.1

 ### Breaking changes
 #### Deprecation of Restic
-According to [Velero deprecation policy](https://github.com/velero-io/velero/blob/main/GOVERNANCE.md#deprecation-policy), backup of fs-backup under Restic path is removed in v1.17, so `--uploader-type=restic` is not a valid installation configuration anymore. This means you cannot create a backup under Restic path, but you can still restore from the previous backups under Restic path until v1.19.  
+According to [Velero deprecation policy](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#deprecation-policy), backup of fs-backup under Restic path is removed in v1.17, so `--uploader-type=restic` is not a valid installation configuration anymore. This means you cannot create a backup under Restic path, but you can still restore from the previous backups under Restic path until v1.19.  

 #### Repository maintenance job configurations are removed from Velero server parameter
 Since the repository maintenance job configurations are moved to repository maintenance job configMap, in v1.17 below Velero sever parameters are removed:
@@ -1,7 +1,7 @@
 ## v1.18

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.18.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.18.0

 ### Container Image
 `velero/velero:v1.18.0`
@@ -16,7 +16,7 @@ https://velero.io/docs/v1.18/upgrade-to-1.18/
 #### Concurrent backup
 In v1.18, Velero is capable to process multiple backups concurrently. This is a significant usability improvement, especially for multiple tenants or multiple users case, backups submitted from different users could run their backups simultaneously without interfering with each other.  

-Check design https://github.com/velero-io/velero/blob/main/design/Implemented/concurrent-backup-processing.md for more details.
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/concurrent-backup-processing.md for more details.

 #### Cache volume for data movers
 In v1.18, Velero allows users to configure cache volumes for data mover pods during restore for CSI snapshot data movement and fs-backup. This brings below benefits:
@@ -24,7 +24,7 @@ In v1.18, Velero allows users to configure cache volumes for data mover pods dur
 - Solve the problem that multiple data mover pods fail to run concurrently in one node when the node's ephemeral disk is limited
 - Working together with backup repository's cache limit configuration, cache volume with appropriate size helps to improve the restore throughput

-Check design https://github.com/velero-io/velero/blob/main/design/Implemented/backup-repo-cache-volume.md for more details.
+Check design https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/backup-repo-cache-volume.md for more details.

 #### Incremental size for data movers
 In v1.18, Velero allows users to observe the incremental size of data movers backups for CSI snapshot data movement and fs-backup, so that users could visually see the data reduction due to incremental backup.
@@ -53,7 +53,7 @@ kopia: 0.22.3

 ### Breaking changes
 #### Deprecation of PVC selected node feature
-According to [Velero deprecation policy](https://github.com/velero-io/velero/blob/main/GOVERNANCE.md#deprecation-policy), PVC selected node feature is deprecated in v1.18. Velero could appropriately handle PVC's selected-node annotation, so users don't need to do anything particularly.
+According to [Velero deprecation policy](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#deprecation-policy), PVC selected node feature is deprecated in v1.18. Velero could appropriately handle PVC's selected-node annotation, so users don't need to do anything particularly.

 ### All Changes
 * Remove backup from running list when backup fails validation (#9498, @sseago)
@@ -2,7 +2,7 @@
 #### 2019-11-07

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.2.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.2.0

 ### Container Image
 `velero/velero:v1.2.0`
@@ -2,7 +2,7 @@
 ### 2020-04-03

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.3.2
+https://github.com/vmware-tanzu/velero/releases/tag/v1.3.2

 ### Container Image
 `velero/velero:v1.3.2`
@@ -21,7 +21,7 @@ https://velero.io/docs/v1.3.2/upgrade-to-1.3/
 ### 2020-03-10

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.3.1
+https://github.com/vmware-tanzu/velero/releases/tag/v1.3.1

 ### Container Image
 `velero/velero:v1.3.1`
@@ -44,7 +44,7 @@ Fixed a bug that caused failures when backing up CustomResourceDefinitions with
 #### 2020-03-02

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.3.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.3.0

 ### Container Image
 `velero/velero:v1.3.0`
@@ -83,10 +83,10 @@ For more information on manifest lists, see [Docker’s documentation](https://d

 We fixed a large number of bugs and made some smaller usability improvements in this release. Here are a few highlights:

- Support private registries with custom ports for the restic restore helper image ([PR #1999](https://github.com/velero-io/velero/pull/1999), [@cognoz](https://github.com/cognoz))
- Use AWS profile from BackupStorageLocation when invoking restic ([PR #2096](https://github.com/velero-io/velero/pull/2096), [@dinesh](https://github.com/dinesh))
- Allow restores from schedules in other clusters ([PR #2218](https://github.com/velero-io/velero/pull/2218), [@cpanato](https://github.com/cpanato))
- Fix memory leak & race condition in restore code ([PR #2201](https://github.com/velero-io/velero/pull/2201), [@skriss](https://github.com/skriss))
+- Support private registries with custom ports for the restic restore helper image ([PR #1999](https://github.com/vmware-tanzu/velero/pull/1999), [@cognoz](https://github.com/cognoz))
+- Use AWS profile from BackupStorageLocation when invoking restic ([PR #2096](https://github.com/vmware-tanzu/velero/pull/2096), [@dinesh](https://github.com/dinesh))
+- Allow restores from schedules in other clusters ([PR #2218](https://github.com/vmware-tanzu/velero/pull/2218), [@cpanato](https://github.com/cpanato))
+- Fix memory leak & race condition in restore code ([PR #2201](https://github.com/vmware-tanzu/velero/pull/2201), [@skriss](https://github.com/skriss))


 ### All Changes
@@ -2,7 +2,7 @@
 ### 2020-07-13

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.4.2
+https://github.com/vmware-tanzu/velero/releases/tag/v1.4.2

 ### Container Image
 `velero/velero:v1.4.2`
@@ -27,7 +27,7 @@ This tag was created in code, but has no associated docker image due to misconfi
 ### 2020-05-26

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.4.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.4.0

 ### Container Image
 `velero/velero:v1.4.0`
@@ -2,7 +2,7 @@
 ### 2020-09-16

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.5.1
+https://github.com/vmware-tanzu/velero/releases/tag/v1.5.1

 ### Container Image
 `velero/velero:v1.5.1`
@@ -57,7 +57,7 @@ Displays the Timestamps when issued a print or describe (#2748, @thejasbabu)
  * StorageGrid compatibility by removing explicit gzip accept header setting (#2712, @fvsqr)
  * restic: add support for setting SecurityContext (runAsUser, runAsGroup) for restore (#2621, @jaygridley)
  * Add backupValidationFailureTotal to metrics (#2714, @kathpeony)
-  * bump Kubernetes module dependencies to v0.18.4 to fix https://github.com/velero-io/velero/issues/2540 by adding code compatibility with kubernetes v1.18 (#2651, @laverya)
+  * bump Kubernetes module dependencies to v0.18.4 to fix https://github.com/vmware-tanzu/velero/issues/2540 by adding code compatibility with kubernetes v1.18 (#2651, @laverya)
  * Add a BSL controller to handle validation + update BSL status phase (validation removed from the server and no longer blocks when there's any invalid BSL) (#2674, @carlisia)
  * updated acceptable values on cron schedule from 0-7 to 0-6 (#2676, @dthrasher)
  * Improve velero download doc (#2660, @carlisia)
@@ -2,7 +2,7 @@
 ### 2021-04-12

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.6.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.6.0

 ### Container Image
 `velero/velero:v1.6.0`
@@ -2,7 +2,7 @@
 ### 2021-09-07

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.7.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.7.0

 ### Container Image
 `velero/velero:v1.7.0`
@@ -75,6 +75,6 @@ This command collects information about a Velero installation, such as pod logs
  * 🐛 Fix plugin name derivation from image name (#3711, @ashish-amarnath)
  * ✨ ⚠️ Remove CSI volumesnapshot artifact deletion

-This change requires https://github.com/velero-io/velero-plugin-for-csi/pull/86 for Velero to continue
+This change requires https://github.com/vmware-tanzu/velero-plugin-for-csi/pull/86 for Velero to continue
 deleting of CSI volumesnapshots when the corresponding backups are deleted. (#3734, @ashish-amarnath)
  * use unstructured to marshal selective fields for service restore action (#3789, @alaypatel07)
@@ -2,7 +2,7 @@
 ### 2022-01-14

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.8.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.8.0

 ### Container Image
 `velero/velero:v1.8.0`
@@ -41,7 +41,7 @@ When a Backup Storage Location (BSL) is deleted, backup and Restic repository re

 #### Breaking changes

-Starting in v1.8, Velero will only support Kubernetes v1 CRD meaning that Velero v1.8+ will only run on Kubernetes v1.16+. Before upgrading, make sure you are running a supported Kubernetes version. For more information, see our [compatibility matrix](https://github.com/velero-io/velero#velero-compatibility-matrix).
+Starting in v1.8, Velero will only support Kubernetes v1 CRD meaning that Velero v1.8+ will only run on Kubernetes v1.16+. Before upgrading, make sure you are running a supported Kubernetes version. For more information, see our [compatibility matrix](https://github.com/vmware-tanzu/velero#velero-compatibility-matrix).

 #### Upload Progress Monitoring and Item Snapshotter
 Item Snapshotter plugin API was merged.  This will support both Upload Progress
@@ -2,7 +2,7 @@
 ### 2022-06-13

 ### Download
-https://github.com/velero-io/velero/releases/tag/v1.9.0
+https://github.com/vmware-tanzu/velero/releases/tag/v1.9.0

 ### Container Image
 `velero/velero:v1.9.0`
@@ -20,7 +20,7 @@ https://velero.io/docs/v1.9/upgrade-to-1.9/
 - No VolumeSnapshot will be left in the source namespace of the workload
 - Report metrics for CSI snapshots

-More improvements please refer to [CSI plugin improvement](https://github.com/velero-io/velero/issues?q=is%3Aissue+label%3A%22CSI+plugin+-+GA+-+phase1%22+is%3Aclosed)
+More improvements please refer to [CSI plugin improvement](https://github.com/vmware-tanzu/velero/issues?q=is%3Aissue+label%3A%22CSI+plugin+-+GA+-+phase1%22+is%3Aclosed)

 With these improvements we'll provide official support for CSI snapshots on AKS/EKS clusters. (with CSI plugin v0.3.0)

@@ -22,8 +22,8 @@ import (

 	"k8s.io/klog/v2"

-	"github.com/velero-io/velero/pkg/cmd"
-	"github.com/velero-io/velero/pkg/cmd/velero"
+	"github.com/vmware-tanzu/velero/pkg/cmd"
+	"github.com/vmware-tanzu/velero/pkg/cmd/velero"
 )

 func main() {
@@ -20,7 +20,7 @@ Update the `velero backup-location delete <bsl name>` command to delete associat

 ## Non Goals

-[It was suggested](https://github.com/velero-io/velero/issues/2082#issuecomment-827951311) to fix bug #2697 alongside this issue.
+[It was suggested](https://github.com/vmware-tanzu/velero/issues/2082#issuecomment-827951311) to fix bug #2697 alongside this issue.
 However, I think that should be fixed separately because although it is similar (restore objects are not being deleted), it is also quite different.
 One is adding a command feature update (this issue) and the other is a bug fix and each affect different parts of the code base.

@@ -31,7 +31,7 @@ Update the `velero backup-location delete <bsl name>` command to do the followin
 - find in the same Velero namespace from which the BSL was deleted the associated backup resources and Restic repositories, called "backups.velero.io" and "resticrepositories.velero.io" respectively
 - delete the resources found

-The above logic will be added to [where BSLs are deleted](https://github.com/velero-io/velero/blob/main/pkg/cmd/cli/backuplocation/delete.go).
+The above logic will be added to [where BSLs are deleted](https://github.com/vmware-tanzu/velero/blob/main/pkg/cmd/cli/backuplocation/delete.go).

 ## Alternative Considered

@@ -2,7 +2,7 @@

 ## Abstract

-Currently, the [VolumePolicies feature](https://github.com/velero-io/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md) which can be used to filter/handle volumes during backup only supports the skip action on matching conditions. Users need more actions to be supported.
+Currently, the [VolumePolicies feature](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md) which can be used to filter/handle volumes during backup only supports the skip action on matching conditions. Users need more actions to be supported.

 ## Background

@@ -58,17 +58,17 @@ volumePolicies:
 ```
 ## High-Level Design
 - When the VolumePolicy action is set as `fs-backup` the backup workflow modifications would be:
-  - We call [backupItem() -> backupItemInternal()](https://github.com/velero-io/velero/blob/main/pkg/backup/item_backupper.go#L95) on all the items that are to be backed up
-  - Here when we encounter [Pod as an item ](https://github.com/velero-io/velero/blob/main/pkg/backup/item_backupper.go#L195)
+  - We call [backupItem() -> backupItemInternal()](https://github.com/vmware-tanzu/velero/blob/main/pkg/backup/item_backupper.go#L95) on all the items that are to be backed up
+  - Here when we encounter [Pod as an item ](https://github.com/vmware-tanzu/velero/blob/main/pkg/backup/item_backupper.go#L195)
  - We will have to modify the backup workflow to account for the `fs-backup` VolumePolicy action


 - When the VolumePolicy action is set as `snapshot` the backup workflow modifications would be:
-  - Once again, We call [backupItem() -> backupItemInternal()](https://github.com/velero-io/velero/blob/main/pkg/backup/item_backupper.go#L95) on all the items that are to be backed up
-  - Here when we encounter [Persistent Volume as an item](https://github.com/velero-io/velero/blob/d4128542590470b204a642ee43311921c11db880/pkg/backup/item_backupper.go#L253)
-  - And we call the [takePVSnapshot func](https://github.com/velero-io/velero/blob/d4128542590470b204a642ee43311921c11db880/pkg/backup/item_backupper.go#L508)
+  - Once again, We call [backupItem() -> backupItemInternal()](https://github.com/vmware-tanzu/velero/blob/main/pkg/backup/item_backupper.go#L95) on all the items that are to be backed up
+  - Here when we encounter [Persistent Volume as an item](https://github.com/vmware-tanzu/velero/blob/d4128542590470b204a642ee43311921c11db880/pkg/backup/item_backupper.go#L253)
+  - And we call the [takePVSnapshot func](https://github.com/vmware-tanzu/velero/blob/d4128542590470b204a642ee43311921c11db880/pkg/backup/item_backupper.go#L508)
  - We need to modify the takePVSnapshot function to account for the `snapshot` VolumePolicy action.
-  - In case of csi snapshots for PVC objects, these snapshot actions are taken by the velero-plugin-for-csi, we need to modify the [executeActions()](https://github.com/velero-io/velero/blob/512fe0dabdcb3bbf1ca68a9089056ae549663bcf/pkg/backup/item_backupper.go#L232) function to account for the `snapshot` VolumePolicy action.
+  - In case of csi snapshots for PVC objects, these snapshot actions are taken by the velero-plugin-for-csi, we need to modify the [executeActions()](https://github.com/vmware-tanzu/velero/blob/512fe0dabdcb3bbf1ca68a9089056ae549663bcf/pkg/backup/item_backupper.go#L232) function to account for the `snapshot` VolumePolicy action.

 **Note:** `Snapshot` action can either be a native snapshot or a csi snapshot, as is the case with the current flow where velero itself makes the decision based on the backup CR.

@@ -80,9 +80,9 @@ volumePolicies:
  - Else continue with the annotation based legacy approach workflow.

 - Modifications needed for `snapshot` action:
-  - In the [takePVSnapshot function](https://github.com/velero-io/velero/blob/d4128542590470b204a642ee43311921c11db880/pkg/backup/item_backupper.go#L508) we will check the PV fits the volume policy criteria and see if the associated action is `snapshot`
+  - In the [takePVSnapshot function](https://github.com/vmware-tanzu/velero/blob/d4128542590470b204a642ee43311921c11db880/pkg/backup/item_backupper.go#L508) we will check the PV fits the volume policy criteria and see if the associated action is `snapshot`
  - If it is not snapshot then we skip the further workflow and avoid taking the snapshot of the PV
-  - Similarly, For csi snapshot of PVC object, we need to do similar changes in [executeAction() function](https://github.com/velero-io/velero/blob/512fe0dabdcb3bbf1ca68a9089056ae549663bcf/pkg/backup/item_backupper.go#L348). we will check the PVC fits the volume policy criteria and see if the associated action is `snapshot` via csi plugin
+  - Similarly, For csi snapshot of PVC object, we need to do similar changes in [executeAction() function](https://github.com/vmware-tanzu/velero/blob/512fe0dabdcb3bbf1ca68a9089056ae549663bcf/pkg/backup/item_backupper.go#L348). we will check the PVC fits the volume policy criteria and see if the associated action is `snapshot` via csi plugin
  - If it is not snapshot then we skip the csi BIA execute action and avoid taking the snapshot of the PVC by not invoking the csi plugin action for the PVC

 **Note:**
@@ -338,7 +338,7 @@ In the future, we envision the following actions that can be implemented:

 ## Related to Design

-[Handle backup of volumes by resources filters](https://github.com/velero-io/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md)
+[Handle backup of volumes by resources filters](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/handle-backup-of-volumes-by-resources-filters.md)

 ## Alternatives Considered
 Same as the earlier design as this is an extension of the original VolumePolicies design
@@ -371,4 +371,4 @@ In this design, no new information is added in backup and restore. As a result,

 ## Open Issues
 Please notice the CSI snapshot backup and restore mechanism not supporting all file-store-based volume, e.g. Azure Files, EFS or vSphere CNS File Volume. Only block-based volumes are supported.
-Refer to [this comment](https://github.com/velero-io/velero/issues/3151#issuecomment-2623507686) for more details.
+Refer to [this comment](https://github.com/vmware-tanzu/velero/issues/3151#issuecomment-2623507686) for more details.
@@ -382,7 +382,7 @@ type BackupSpec struct {
 ```

 ## Alternatives Considered
-Proposal from Jibu Data [Issue 5120](https://github.com/velero-io/velero/issues/5120#issue-1304534563)
+Proposal from Jibu Data [Issue 5120](https://github.com/vmware-tanzu/velero/issues/5120#issue-1304534563)

 ## Security Considerations
 No security impact.
@@ -399,4 +399,4 @@ Plan to deprecate `IncludedResources`, `ExcludedResources` and `IncludeClusterRe
 ## Open Issues
 `LabelSelector/OrLabelSelectors` apply to namespace-scoped resources.
 It may be reasonable to make them also working on cluster-scoped resources.
-An issue is created to trace this topic [resource label selector not work for cluster-scoped resources](https://github.com/velero-io/velero/issues/5787)
+An issue is created to trace this topic [resource label selector not work for cluster-scoped resources](https://github.com/vmware-tanzu/velero/issues/5787)
@@ -73,8 +73,8 @@ This same approach can be taken for CA bundles. The bundle can be stored in a
 secret which is referenced on the BSL and written to a temp file prior to
 invoking Restic.

-[1](https://github.com/velero-io/velero/blob/main/pkg/restic/repository_manager.go#L238-L245)
-[2](https://github.com/velero-io/velero/blob/main/pkg/restic/common.go#L168-L203)
+[1](https://github.com/vmware-tanzu/velero/blob/main/pkg/restic/repository_manager.go#L238-L245)
+[2](https://github.com/vmware-tanzu/velero/blob/main/pkg/restic/common.go#L168-L203)

 ## Detailed Design

@@ -126,7 +126,7 @@ would look like:
 $ velero client config set cacert PATH
 ```

-[1]: https://github.com/velero-io/velero-plugin-for-aws/blob/main/velero-plugin-for-aws/object_store.go#L135
-[2]: https://github.com/velero-io/velero/blob/main/pkg/restic/command.go#L47
+[1]: https://github.com/vmware-tanzu/velero-plugin-for-aws/blob/main/velero-plugin-for-aws/object_store.go#L135
+[2]: https://github.com/vmware-tanzu/velero/blob/main/pkg/restic/command.go#L47
 [3]: https://github.com/restic/restic/blob/main/internal/backend/http_transport.go#L81
-[4]: https://github.com/velero-io/velero-plugin-for-aws/blob/main/velero-plugin-for-aws/object_store.go#L154
+[4]: https://github.com/vmware-tanzu/velero-plugin-for-aws/blob/main/velero-plugin-for-aws/object_store.go#L154
@@ -8,12 +8,12 @@ As of Today, Velero will skip over the restoration of resources that already exi
 - Fetches the `service` from the cluster 
 - If the `service` exists then:
    - Checks whether the `service` instance in the cluster is equal to the `service`  instance present in backup
-        - If not equal then skips the restore of the `service` and adds a restore warning (except for [ServiceAccount objects](https://github.com/velero-io/velero/blob/574baeb3c920f97b47985ec3957debdc70bcd5f8/pkg/restore/restore.go#L1246))
+        - If not equal then skips the restore of the `service` and adds a restore warning (except for [ServiceAccount objects](https://github.com/vmware-tanzu/velero/blob/574baeb3c920f97b47985ec3957debdc70bcd5f8/pkg/restore/restore.go#L1246))
        - If equal then skips the restore of the `service` and mentions that the restore of resource `service` is skipped in logs

 It is desired to add the functionality to specify whether or not to overwrite the instance of resource `service` in cluster with the one present in backup during the restore process.

-Related issue: https://github.com/velero-io/velero/issues/4066
+Related issue: https://github.com/vmware-tanzu/velero/issues/4066

 ## Goals
 - Add support for `ExistingResourcePolicy` to restore API for Kubernetes resources.
@@ -31,7 +31,7 @@ Related issue: https://github.com/velero-io/velero/issues/4066
 ### A. Production Cluster - Backup Cluster:
 Let's say you have a Backup Cluster which is identical to the Production Cluster. After some operations/usage/time the Production Cluster had changed itself, there might be new deployments, some secrets might have been updated. Now, this means that the Backup cluster will no longer be identical to the Production Cluster. In order to keep the Backup Cluster up to date/identical to the Production Cluster with respect to Kubernetes resources except PV data we would like to use Velero for scheduling new backups which would in turn help us update the Backup Cluster via Velero restore.

-Reference: https://github.com/velero-io/velero/issues/4066#issuecomment-954320686
+Reference: https://github.com/vmware-tanzu/velero/issues/4066#issuecomment-954320686

 ### B. Help identify resource delta:
 Here delta resources mean the resources restored by a previous backup, but they are no longer in the latest backup. Let's follow a sequence of steps to understand this scenario:
@@ -43,7 +43,7 @@ Here delta resources mean the resources restored by a previous backup, but they
 - So the Delta here is (|Cluster B - Backup2|), Delete P1 and Update P2.
 - During Restore time we would want the Restore to help us identify this resource delta.

-Reference: https://github.com/velero-io/velero/pull/4613#issuecomment-1027260446
+Reference: https://github.com/vmware-tanzu/velero/pull/4613#issuecomment-1027260446

 ## High-Level Design
 ### Approach 1: Add a new spec field `existingResourcePolicy` to the Restore API
@@ -238,7 +238,7 @@ IncludedResources []string
 }
 ```

-The restore workflow changes will be done [here](https://github.com/velero-io/velero/blob/b40bbda2d62af2f35d1406b9af4d387d4b396839/pkg/restore/restore.go#L1245)
+The restore workflow changes will be done [here](https://github.com/vmware-tanzu/velero/blob/b40bbda2d62af2f35d1406b9af4d387d4b396839/pkg/restore/restore.go#L1245)

 ### CLI changes for Approach 1
 We would introduce a new CLI flag called `existing-resource-policy` of string type. This flag would be used to accept the 
@@ -526,24 +526,24 @@ updates. Here is a list of some of these items:
 1. Consts for the "Uploading" and "UploadingPartiallyFailed" phases have already been defined. These
   will need to be removed when the "WaitingForPluginOperations" and
   "WaitingForPluginOperationsPartiallyFailed" phases are defined.
-   - https://github.com/velero-io/velero/pull/3805
+   - https://github.com/vmware-tanzu/velero/pull/3805
 1. Remove the ItemSnapshotter plugin APIs (and related code) since the revised design will reuse
   VolumeSnapshotter and BackupItemAction plugins.
-   - https://github.com/velero-io/velero/pull/4077
-   - https://github.com/velero-io/velero/pull/4417
+   - https://github.com/vmware-tanzu/velero/pull/4077
+   - https://github.com/vmware-tanzu/velero/pull/4417
 1. UploadProgressFeatureFlag shouldn't be needed anymore. The current design won't really need a
   feature flag here -- the new features will be added to V2 of the VolumeSnapshotter,
   BackupItemAction, and RestoreItemAction plugins, and it will only be used if there are plugins which
   return operation IDs.
-   - https://github.com/velero-io/velero/pull/4416
+   - https://github.com/vmware-tanzu/velero/pull/4416
 1. Adds <backup-name>-itemsnapshots.gz file to backup (when provided) -- this is still part of the
   revised design, so it should stay.
-   - https://github.com/velero-io/velero/pull/4429
+   - https://github.com/vmware-tanzu/velero/pull/4429
 1. Upload Progress Monitoring and Item Snapshotter basic support: This PR is not yet merged, so
   nothing will need to be reverted. While the implementation here will be useful in informing the
   implementation of the new design, several things have changed in the design proposal since the PR
   was written.
-   - https://github.com/velero-io/velero/pull/4467
+   - https://github.com/vmware-tanzu/velero/pull/4467

 # Implementation tasks

@@ -4,7 +4,7 @@ This enhancement will allow the user to set include and exclude filters for reso
 these filters are reusable and the user will not need to set them each time they create a backup.

 ## Background
-As mentioned in issue [#8610](https://github.com/velero-io/velero/issues/8610).  When there's a long list of resources 
+As mentioned in issue [#8610](https://github.com/vmware-tanzu/velero/issues/8610).  When there's a long list of resources 
 to include or exclude in a backup, it can be cumbersome to set them each time a backup is created.  There's a requirement to
 set these filters in a separate data structure so that they can be reused in multiple backups.

@@ -150,7 +150,7 @@ Compatibility with existing StorageClass mapping RestoreItemAction and similar p

 ## Implementation
 - Changes in Restore CRD. Add a new field to the RestoreSpec to reference the configmap.
- One example of where code will be modified:  https://github.com/velero-io/velero/blob/eeee4e06d209df7f08bfabda326b27aaf0054759/pkg/restore/restore.go#L1266 On the obj before Creation, we can apply the conditions to check if the resource is filtered out using given parameters. Then using JsonPatch provided, we can update the resource.
+- One example of where code will be modified:  https://github.com/vmware-tanzu/velero/blob/eeee4e06d209df7f08bfabda326b27aaf0054759/pkg/restore/restore.go#L1266 On the obj before Creation, we can apply the conditions to check if the resource is filtered out using given parameters. Then using JsonPatch provided, we can update the resource.
 - For Jsonpatch - https://github.com/evanphx/json-patch library is used.
 - JSON Patch RFC https://datatracker.ietf.org/doc/html/rfc6902

@@ -49,7 +49,7 @@ This proposal is to add support for JSON Merge Patch and Strategic Merge Patch i
 - New fields `MergePatches` and `StrategicPatches` will be added to the `ResourceModifierRule` struct to support all three patch types.
 - Only one of the three patch types can be specified in a single `ResourceModifierRule`.
 - Add wildcard support for `groupResource` in `conditions` struct.
- The workflow to create Resource Modifier ConfigMap and reference it in RestoreSpec will remain the same as described in document [Resource Modifiers](https://github.com/velero-io/velero/blob/main/site/content/docs/main/restore-resource-modifiers.md).
+- The workflow to create Resource Modifier ConfigMap and reference it in RestoreSpec will remain the same as described in document [Resource Modifiers](https://github.com/vmware-tanzu/velero/blob/main/site/content/docs/main/restore-resource-modifiers.md).

 ### How to choose the right patch type
 - [JSON Merge Patch](https://datatracker.ietf.org/doc/html/rfc7386) is a naively simple format, with limited usability. Probably it is a good choice if you are building something small, with very simple JSON Schema.
@@ -187,7 +187,7 @@ Compatible with current Resource Modifiers.

 ## Future enhancements
 - add a Velero subcommand to generate/validate the patchData for Strategic Merge Patch and JSON Merge Patch.
- add jq support for more complex conditions or patches, to meet the situations that the current conditions or patches can not handle. like [this issue](https://github.com/velero-io/velero/issues/6344)
+- add jq support for more complex conditions or patches, to meet the situations that the current conditions or patches can not handle. like [this issue](https://github.com/vmware-tanzu/velero/issues/6344)

 ## Open Issues
 N/A
@@ -17,7 +17,7 @@ Currently, the Velero repository sits under the Heptio GitHub organization. With
 #### Pre move

 - [ ] PR: Blog post communicating the move. https://github.com/heptio/velero/issues/1841. Who: TBD.
- [ ] PR: Find/replace in all Go, script, yaml, documentation, and website files: `github.com/heptio/velero -> github.com/velero-io/velero`. Who: a Velero developer; TBD
+- [ ] PR: Find/replace in all Go, script, yaml, documentation, and website files: `github.com/heptio/velero -> github.com/vmware-tanzu/velero`. Who: a Velero developer; TBD
 - [ ] PR: Update website with the correct GH links. Who: a Velero developer; TBD
 - [ ] PR: Change deployment and grpc-push scripts with the new location path. Who: a Velero developer; TBD
 - [ ] Delete branches not to be carried over (https://github.com/heptio/velero/branches/all). Who: Any of the current repo owners; TBD
@@ -32,7 +32,7 @@ Currently, the Velero repository sits under the Heptio GitHub organization. With

 #### Post move

- [ ] Each individual developer should point their origin to the new location: `git remote set-url origin git@github.com:velero-io/velero.git`
+- [ ] Each individual developer should point their origin to the new location: `git remote set-url origin git@github.com:vmware-tanzu/velero.git`
 - [ ] Transfer ZenHub. Who: Any of the new repo owners; TBD
 - [ ] Update Netlify deploy settings. Any of the new repo owners; TBD
 - [ ] GH app: Netlify integration. Who: Any of the new repo owners; TBD
@@ -95,7 +95,7 @@ The Velero CSI plugin chooses the VolumeSnapshotClass in the cluster that has th
    We can add support for  - velero backup create my-backup --annotations "velero.io/csi:csi.cloud.disk.driver=csi-diskdriver-snapclass"

 ### Stage 2 Approach
-The above annotations route is to get started and for initial design closure/ implementation, north star is to either introduce CSI specific fields (considering that CSI might be a very core part of velero going forward) in the backup/restore CR OR leverage the pluginInputs field as being tracked in: https://github.com/velero-io/velero/pull/5981
+The above annotations route is to get started and for initial design closure/ implementation, north star is to either introduce CSI specific fields (considering that CSI might be a very core part of velero going forward) in the backup/restore CR OR leverage the pluginInputs field as being tracked in: https://github.com/vmware-tanzu/velero/pull/5981

 Refer section Alternatives 2. **Through generic property bag in the velero contracts**: in the design doc for more details on the pluginInputs field.

@@ -14,7 +14,7 @@ backup for resources consisting of a label from a set of labels (label1 OR label
 create multiple backups per label rule. It would be really useful if Velero Backup API could respect a set of
 labels (OR Rule) for a single backup request.

-Related Issue: https://github.com/velero-io/velero/issues/1508
+Related Issue: https://github.com/vmware-tanzu/velero/issues/1508

 ## Goals
 - Enable support for backing up resources based on multiple labels (OR Logic) in a single backup config.
@@ -130,9 +130,9 @@ OrLabelSelectors []\*metav1.LabelSelector
 ```

 The logic to collect resources to be backed up for a particular backup will be updated in the `backup/item_collector.go`
-around [here](https://github.com/velero-io/velero/blob/574baeb3c920f97b47985ec3957debdc70bcd5f8/pkg/backup/item_collector.go#L294).
+around [here](https://github.com/vmware-tanzu/velero/blob/574baeb3c920f97b47985ec3957debdc70bcd5f8/pkg/backup/item_collector.go#L294).

-And for filtering the resources to be restored, the changes will go [here](https://github.com/velero-io/velero/blob/d1063bda7e513150fd9ae09c3c3c8b1115cb1965/pkg/restore/restore.go#L1769)
+And for filtering the resources to be restored, the changes will go [here](https://github.com/vmware-tanzu/velero/blob/d1063bda7e513150fd9ae09c3c3c8b1115cb1965/pkg/restore/restore.go#L1769)

 **Note:**
 - This feature will not be exposed via Velero CLI.
@@ -154,7 +154,7 @@ In order to know the CR created for the particular backup of a volume, Velero ad
 - `velero.io/pv-name` with value as volume that is undergoing backup

 Backup name being unique won't cause issues like duplicates in identifying the CR.
-Labels will be set with the value returned from `GetValidName` function. (https://github.com/velero-io/velero/blob/main/pkg/label/label.go#L35).
+Labels will be set with the value returned from `GetValidName` function. (https://github.com/vmware-tanzu/velero/blob/main/pkg/label/label.go#L35).

 If Plugin supports showing progress of the operation it is performing, it does following:
 - finds the VolumePluginBackup CR related to this backup operation by using `tags` passed in CreateSnapshot call
@@ -281,7 +281,7 @@ In order to know the CR created for the particular restore of a volume, Velero a
 - `velero.io/snapshot-id` with value as snapshot id that need to be restored
 - `velero.io/provider` with value as `Provider` in `VolumeSnapshotLocation`

-Labels will be set with the value returned from `GetValidName` function. (https://github.com/velero-io/velero/blob/main/pkg/label/label.go#L35).
+Labels will be set with the value returned from `GetValidName` function. (https://github.com/vmware-tanzu/velero/blob/main/pkg/label/label.go#L35).

 Plugin will be able to identify CR by using snapshotID that it received as parameter of CreateVolumeFromSnapshot API, and plugin's Provider name.
 It updates the progress of restore operation regularly if plugin supports feature of showing progress.
@@ -376,7 +376,7 @@ In order to know the CR created for the particular backup of a volume, volume sn

 Backup name being unique won't cause issues like duplicates in identifying the CR.

-Plugin need to sanitize the value that can be set for above labels. Label need to be set with the value returned from `GetValidName` function. (https://github.com/velero-io/velero/blob/main/pkg/label/label.go#L35).
+Plugin need to sanitize the value that can be set for above labels. Label need to be set with the value returned from `GetValidName` function. (https://github.com/vmware-tanzu/velero/blob/main/pkg/label/label.go#L35).

 Though no restrictions are required on the name of CR, as a general practice, volume snapshotter can name this CR with the value same as return value of CreateSnapshot.

@@ -92,7 +92,7 @@ type ObjectStore interface {
 If a method is being added to the `ObjectStore` API, a file would be added to `pkg/plugin/velero/objectstore/v2/` and may contain a new API definition as follows:

 ```
-import "github.com/velero-io/velero/pkg/plugin/velero/objectstore/v1"
+import "github.com/vmware-tanzu/velero/pkg/plugin/velero/objectstore/v1"

 type ObjectStore interface {
    // Import all the methods from the previous version of the API if they are to be included as is
@@ -147,15 +147,15 @@ The message definitions can be shared however, so these could be extracted from
 ### Plugin Framework

 To allow plugins to register which versions of the API they implement, the plugin framework will need to be adapted to accept new versions.
-Currently, the plugin manager stores a [`map[string]RestartableProcess`](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L69), where the string key is the binary name for the plugin process (e.g. "velero-plugin-for-aws").
-Each `RestartableProcess` contains a [`map[kindAndName]interface{}`](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/restartable_process.go#L60) which represents each of the unique plugin implementations provided by that binary.
-[`kindAndName`](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/registry.go#L42) is a struct which combines the plugin kind (`ObjectStore`, `VolumeSnapshotter`) and the plugin name ("velero.io/aws", "velero.io/azure").
+Currently, the plugin manager stores a [`map[string]RestartableProcess`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L69), where the string key is the binary name for the plugin process (e.g. "velero-plugin-for-aws").
+Each `RestartableProcess` contains a [`map[kindAndName]interface{}`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/restartable_process.go#L60) which represents each of the unique plugin implementations provided by that binary.
+[`kindAndName`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/registry.go#L42) is a struct which combines the plugin kind (`ObjectStore`, `VolumeSnapshotter`) and the plugin name ("velero.io/aws", "velero.io/azure").

 Each plugin version registration must be unique (to allow for multiple versions to be implemented within the same plugin binary).
 This will be achieved by adding a specific registration method for each version to the Server interface in the plugin framework.
 For example, if adding a V2 `RestoreItemAction` plugin, the Server interface would be modified to add the `RegisterRestoreItemActionV2` method.
-This would require [adding a new plugin Kind const](https://github.com/velero-io/velero/blob/main/pkg/plugin/framework/plugin_kinds.go#L28-L46) to represent the new plugin version, e.g. `PluginKindRestoreItemActionV2`.
-It also requires the creation of a new implementation of the go-plugin interface ([example](https://github.com/velero-io/velero/blob/main/pkg/plugin/framework/object_store.go)) to support that version and use the generated gRPC code from the proto definition (including a client and server implementation).
+This would require [adding a new plugin Kind const](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/framework/plugin_kinds.go#L28-L46) to represent the new plugin version, e.g. `PluginKindRestoreItemActionV2`.
+It also requires the creation of a new implementation of the go-plugin interface ([example](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/framework/object_store.go)) to support that version and use the generated gRPC code from the proto definition (including a client and server implementation).
 The Server will also need to be adapted to recognize this new plugin Kind and to serve the new implementation.

 Existing plugin Kind consts and registration methods will be left unchanged and will correspond to the current version of the plugin APIs (assumed to be v1).
@@ -241,7 +241,7 @@ In cases where the methods signatures remain the same, the adaptation layer will
 Examples where an adaptation may be safe:
 - A method signature is being changed to add a new parameter but the parameter could be optional (for example, adding a context parameter). The adaptation could call through to the method provided in the previous version but omit the parameter.
 - A method signature is being changed to remove a parameter, but it is safe to pass a default value to the previous version. The adaptation could call through to the method provided in the previous version but use a default value for the parameter.
- A new method is being added but does not impact any existing behaviour of Velero (for example, a new method which will allow Velero to [wait for additional items to be ready](https://github.com/velero-io/velero/blob/main/design/Implemented/wait-for-additional-items.md)). The adaptation would return a value which allows the existing behaviour to be performed.
+- A new method is being added but does not impact any existing behaviour of Velero (for example, a new method which will allow Velero to [wait for additional items to be ready](https://github.com/vmware-tanzu/velero/blob/main/design/Implemented/wait-for-additional-items.md)). The adaptation would return a value which allows the existing behaviour to be performed.
 - A method is being deleted as it is no longer used. The adaptation would call through to any methods which are still included but would omit the deleted method in the adaptation.

 Examples where an adaptation may not be safe:
@@ -32,11 +32,11 @@ It will also update the `spec.volumeName` of the related persistent volume claim

 ## Detailed Design

-In `pkg/restore/restore.go`, around [line 872](https://github.com/velero-io/velero/blob/main/pkg/restore/restore.go#L872), Velero has special-case code for persistent volumes.
+In `pkg/restore/restore.go`, around [line 872](https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L872), Velero has special-case code for persistent volumes.
 This code will be updated to check for the two preconditions described in the previous section.
 If the preconditions are met, the object will be given a new name.
 The persistent volume will also be annotated with the original name, e.g. `velero.io/original-pv-name=NAME`.
-Importantly, the name change will occur **before** [line 890](https://github.com/velero-io/velero/blob/main/pkg/restore/restore.go#L890), where Velero checks to see if it should restore the persistent volume.
+Importantly, the name change will occur **before** [line 890](https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L890), where Velero checks to see if it should restore the persistent volume.
 Additionally, the old and new persistent volume names will be recorded in a new field that will be added to the `context` struct, `renamedPVs map[string]string`.

 In the special-case code for persistent volume claims starting on [line 987](https://github.com/heptio/velero/blob/main/pkg/restore/restore.go#L987), Velero will check to see if the claimed persistent volume has been renamed by looking in `ctx.renamedPVs`.
@@ -9,7 +9,7 @@ This new additional metadata file is needed when:
 * Retrieve the PV's snapshot information for backup.

 ## Background
-There is already a [PR](https://github.com/velero-io/velero/pull/6496) to track the skipped PVC in the backup. This design will depend on it and go further to get a summary of PVC and PV information, then persist into a metadata file in the backup repository.
+There is already a [PR](https://github.com/vmware-tanzu/velero/pull/6496) to track the skipped PVC in the backup. This design will depend on it and go further to get a summary of PVC and PV information, then persist into a metadata file in the backup repository.

 In the restore process, the Velero server needs to decide how the PV resource should be restored according to how the PV is backed up. The current logic is to check whether it's backed up by Velero-native snapshot, by file-system backup, or having `DeletionPolicy` set as `Delete`.

@@ -28,7 +28,7 @@ Another thing that needs noticing is when describing the backup, there is no gen
 ## High-Level Design
 Create _backup-name_-volumes-info.json metadata file in the backup's repository. This file will be encoded to contain all the PVC and PV information included in the backup. The information covers whether the PV or PVC's data is skipped during backup, how its data is backed up, and the backed-up detail information.

-Please notice that the new metadata file includes all skipped volume information. This is used to address [the second phase needs of skipped volumes information](https://github.com/velero-io/velero/issues/5834#issuecomment-1526624211).
+Please notice that the new metadata file includes all skipped volume information. This is used to address [the second phase needs of skipped volumes information](https://github.com/vmware-tanzu/velero/issues/5834#issuecomment-1526624211).

 The `restoreItem` function can decode the _backup-name_-volumes-info.json file to determine how to handle the PV resource. 

@@ -169,13 +169,13 @@ After introducing the VolumeInfo array, the following logic will be added.
 _backup-name_-volumes-info.json file is deleted during backup deletion.

 ## Alternatives Considered
-The restore process needs more information about how the PVs are backed up to determine whether this PV should be restored. The released branches also need a similar function, but backporting a new feature into previous releases may not be a good idea, so according to [Anshul Ahuja's suggestion](https://github.com/velero-io/velero/issues/6595#issuecomment-1731081580), adding more cases here to support checking PV backed-up by CSI plugin and CSI snapshot data mover: https://github.com/velero-io/velero/blob/5ff5073cc3f364bafcfbd26755e2a92af68ba180/pkg/restore/restore.go#L1206-L1324.
+The restore process needs more information about how the PVs are backed up to determine whether this PV should be restored. The released branches also need a similar function, but backporting a new feature into previous releases may not be a good idea, so according to [Anshul Ahuja's suggestion](https://github.com/vmware-tanzu/velero/issues/6595#issuecomment-1731081580), adding more cases here to support checking PV backed-up by CSI plugin and CSI snapshot data mover: https://github.com/vmware-tanzu/velero/blob/5ff5073cc3f364bafcfbd26755e2a92af68ba180/pkg/restore/restore.go#L1206-L1324.

 ## Security Considerations
 There should be no security impact introduced by this design.

 ## Compatibility
-After this design is implemented, there should be no impact on the existing [skipped PVC summary feature](https://github.com/velero-io/velero/pull/6496).
+After this design is implemented, there should be no impact on the existing [skipped PVC summary feature](https://github.com/vmware-tanzu/velero/pull/6496).

 To support older version backup, which doesn't have the VolumeInfo metadata file, the old logic, which is checking the Velero native snapshots list, PodVolumeBackup list, and PVC DeletionPolicy, is still kept, and supporting CSI snapshots and snapshot data mover logic will be added too.

@@ -139,5 +139,5 @@ The data structures referenced by volume info is shared between both restore and
 we must make sure there will only be incremental changes to the metadata, such that no break change will be introduced to the client.

 ## Open Issues
-https://github.com/velero-io/velero/issues/7546
-https://github.com/velero-io/velero/issues/6478
+https://github.com/vmware-tanzu/velero/issues/7546
+https://github.com/vmware-tanzu/velero/issues/6478
@@ -20,7 +20,7 @@ This design reuses the data structure introduced by design [Velero Generic Data
 - Let user can choose repository maintenance Job running on which nodes.

 ## Non Goals
- There was an [issue](https://github.com/velero-io/velero/issues/7911) to require the whole Job's PodSpec should be configurable. That's not in the scope of this design.
+- There was an [issue](https://github.com/vmware-tanzu/velero/issues/7911) to require the whole Job's PodSpec should be configurable. That's not in the scope of this design.
 - Please notice this new configuration is dedicated for the repository maintenance. Repository itself configuration is not covered.


@@ -43,7 +43,7 @@ Propose to deprecate the `velero server` parameters `--maintenance-job-cpu-reque
 That means those parameters will be deleted in release-1.17.
 After deletion, those resources-related parameters are replaced by the ConfigMap specified by `velero server` CLI's parameter `--repo-maintenance-job-configmap`.
 `--keep-latest-maintenance-jobs` is deleted from `velero server` CLI. It turns into a non-configurable internal parameter, and its value is 3.
-Please check [issue 7923](https://github.com/velero-io/velero/issues/7923) for more information why deleting this parameter.
+Please check [issue 7923](https://github.com/vmware-tanzu/velero/issues/7923) for more information why deleting this parameter.

 ## Design
 This design introduces a new ConfigMap specified by `velero server` CLI parameter `--repo-maintenance-job-configmap` as the source of the repository maintenance job configuration. The specified ConfigMap is read from the namespace where Velero is installed.
@@ -92,7 +92,7 @@ The other keys in the map is the combination of three elements of a BackupReposi
 * The BackupRepository referenced BackupStorageLocation's name.
 * The BackupRepository's type. Possible values are `kopia` and `restic`.

-Those three keys can identify a [unique BackupRepository](https://github.com/velero-io/velero/blob/2fc6300f2239f250b40b0488c35feae59520f2d3/pkg/repository/backup_repo_op.go#L32-L37).
+Those three keys can identify a [unique BackupRepository](https://github.com/vmware-tanzu/velero/blob/2fc6300f2239f250b40b0488c35feae59520f2d3/pkg/repository/backup_repo_op.go#L32-L37).

 If there is a key match with BackupRepository, the key's value is applied to the BackupRepository's maintenance jobs.
 By this way, it's possible to let user configure before the BackupRepository is created.
@@ -76,7 +76,7 @@ metadata:

 We are targeting the implementation of this design for Velero 1.16 release.

-Current restoreStatus logic resides here: https://github.com/velero-io/velero/blob/32a8c62920ad96c70f1465252c0197b83d5fa6b6/pkg/restore/restore.go#L1652
+Current restoreStatus logic resides here: https://github.com/vmware-tanzu/velero/blob/32a8c62920ad96c70f1465252c0197b83d5fa6b6/pkg/restore/restore.go#L1652

 The modified logic would look somewhat like:

@@ -9,7 +9,7 @@ Currently, the restore process enters a terminal phase once all item restoration
 To address this, a new finalization phase should be added to the existing restore workflow. in this phase, all plugin operations and item restoration has been fully completed, which provides a clean opportunity to perform any wrap-up work before termination, improving the overall restore process.

 Wrap-up tasks in Velero can serve several purposes:
- Post-restore modification - Velero can modify the restored data that was temporarily changed for some purpose but required to be changed back finally or data that was newly created but missing some information. For example, [issue6435](https://github.com/velero-io/velero/issues/6435) indicates that some custom settings(like labels, reclaim policy) on restored PVs was lost because those restored PVs was newly dynamically provisioned. Velero can address it by patching the PVs' custom settings back in the finalization phase.
+- Post-restore modification - Velero can modify the restored data that was temporarily changed for some purpose but required to be changed back finally or data that was newly created but missing some information. For example, [issue6435](https://github.com/vmware-tanzu/velero/issues/6435) indicates that some custom settings(like labels, reclaim policy) on restored PVs was lost because those restored PVs was newly dynamically provisioned. Velero can address it by patching the PVs' custom settings back in the finalization phase.
 - Clean up unused data - Velero can identify and delete any data that are no longer needed after a successful restore in the finalization phase.
 - Post-restore validation - Velero can validate the state of restored data and report any errors to help users locate the issue in the finalization phase.

@@ -8,7 +8,7 @@ This document proposes a solution to select an API group version to restore from

 ## Background

-It is possible that between the time a backup has been made and a restore occurs that the target Kubernetes version has incremented more than one version. In such a case where at least a versions of Kubernetes was skipped, the preferred source cluster's API group versions for resources may no longer be supported by the target cluster. With [PR#2373](https://github.com/velero-io/velero/pull/2373), all supported API group versions were backed up if the EnableAPIGroupVersions feature flag was set for Velero. The next step (outlined by this design proposal) will be to see if any of the backed up versions are supported in the target cluster and if so, choose one to restore for each backed up resource.
+It is possible that between the time a backup has been made and a restore occurs that the target Kubernetes version has incremented more than one version. In such a case where at least a versions of Kubernetes was skipped, the preferred source cluster's API group versions for resources may no longer be supported by the target cluster. With [PR#2373](https://github.com/vmware-tanzu/velero/pull/2373), all supported API group versions were backed up if the EnableAPIGroupVersions feature flag was set for Velero. The next step (outlined by this design proposal) will be to see if any of the backed up versions are supported in the target cluster and if so, choose one to restore for each backed up resource.

 ## Goals

@@ -50,19 +50,19 @@ There are six objectives to achieve the above stated goals:

 ### Objective 1: Determine if the APIGroupVersionsFeatureFlag is enabled and Backup Objects use Status.FormatVersion 1.1.0

-For restore to be able to choose from multiple supported backed up versions, the feature flag must have been enabled during the restore processes. Backup objects must also have [Status.FormatVersion == "1.1.0"](https://github.com/velero-io/velero/blob/a1e182e723a8c5f6d4175d8db2361233a94d2502/pkg/backup/backup.go#L58).
+For restore to be able to choose from multiple supported backed up versions, the feature flag must have been enabled during the restore processes. Backup objects must also have [Status.FormatVersion == "1.1.0"](https://github.com/vmware-tanzu/velero/blob/a1e182e723a8c5f6d4175d8db2361233a94d2502/pkg/backup/backup.go#L58).

 The reason for checking for the feature flag during restore is to ensure the user would like to restore a version that might not be the source cluster preferred version. This check is done via `features.IsEnabled(velerov1api.APIGroupVersionsFeatureFlag)`.

 The reason for checking `Status.FormatVersion` is to ensure the changes made by this proposed design is backward compatible. Only with Velero version 1.4 and forward was Format Version 1.1.0 used to structure the backup directories. Format Version 1.1.0 is required for the restore process proposed in this design doc to work. Before v1.4, the backed up files were in a directory structure that will not be recognized by the proposed code changes. In this case, restore should not attempt to restore from multiple versions as they will not exist.

-The [`Status.FormatVersion`](https://github.com/velero-io/velero/blob/6808acd92e30848056a21faf373af03ddb8a3b71/pkg/apis/velero/v1/backup.go#L235) is stored in a `restoreContext` struct field called [`backup`](https://github.com/velero-io/velero/blob/6808acd92e30848056a21faf373af03ddb8a3b71/pkg/restore/restore.go#L229). The full chain is `ctx.backup.Status.FormatVersion`.  
+The [`Status.FormatVersion`](https://github.com/vmware-tanzu/velero/blob/6808acd92e30848056a21faf373af03ddb8a3b71/pkg/apis/velero/v1/backup.go#L235) is stored in a `restoreContext` struct field called [`backup`](https://github.com/vmware-tanzu/velero/blob/6808acd92e30848056a21faf373af03ddb8a3b71/pkg/restore/restore.go#L229). The full chain is `ctx.backup.Status.FormatVersion`.  

 The above two checks can be done inside a new method on the `*restoreContext` object with the method signature `meetsAPIGVRestoreReqs() bool`. This method can remain in the `restore` package, but for organizational purposes, it can be moved to a file called `prioritize_group_version.go`.

 ### Objective 2: List the backed up API group versions

-Currently, in `pkg/restore/restore.go`, in the `execute(...)` method, around [line 363](https://github.com/velero-io/velero/blob/7a103b9eda878769018386ecae78da4e4f8dde83/pkg/restore/restore.go#L363), the resources and their backed up items are saved in a map called `backupResources`.
+Currently, in `pkg/restore/restore.go`, in the `execute(...)` method, around [line 363](https://github.com/vmware-tanzu/velero/blob/7a103b9eda878769018386ecae78da4e4f8dde83/pkg/restore/restore.go#L363), the resources and their backed up items are saved in a map called `backupResources`.

 At this point, the feature flag and format versions can be checked (described in Objective #1). If the requirements are met, the `backedupResources` map can be sent to a method (to be created) with the signature `ctx.chooseAPIVersionsToRestore(backupResources)`. The `ctx` object has the type `*restore.Context`.

@@ -158,7 +158,7 @@ To see example cases with version priorities, see a blog post written by Rafael

 ### Objective 6: Modify the paths to the backup files in the tarball

-The method doing the bulk of the restoration work is `ctx.restoreResource(...)`. Inside this method, around [line 714](https://github.com/velero-io/velero/blob/7a103b9eda878769018386ecae78da4e4f8dde83/pkg/restore/restore.go#L714) in `pkg/restore/restore.go`, the path to backup json file for the item being restored is set.
+The method doing the bulk of the restoration work is `ctx.restoreResource(...)`. Inside this method, around [line 714](https://github.com/vmware-tanzu/velero/blob/7a103b9eda878769018386ecae78da4e4f8dde83/pkg/restore/restore.go#L714) in `pkg/restore/restore.go`, the path to backup json file for the item being restored is set.

 After the groupResource is instantiated at pkg/restore/restore.go:733, and before the `for` loop that ranges through the `items`, the `ctx.chosenGRVsToRestore` map can be checked. If the groupResource exists in the map, the path saved to `resource` variable can be updated.

@@ -7,7 +7,7 @@ If a patch call fails to update status to completion, it should be retried up to
 This design proposes a way to configure timeout for this retry time limit.

 ## Background
-Original Issue: https://github.com/velero-io/velero/issues/7207
+Original Issue: https://github.com/vmware-tanzu/velero/issues/7207

 Velero was performing a restore when the API server was rolling out to a new version.
 It had trouble connecting to the API server, but eventually, the restore was successful.
@@ -17,7 +17,7 @@ After the connection was restored, it didn't attempt to update, causing the rest
 This can lead to incorrect decisions for other components that rely on the backup/restore CR status to determine completion.

 ## Goals
- Make timeout configurable for retry patching by reusing existing [`--resource-timeout` server flag](https://github.com/velero-io/velero/blob/d9ca14747925630664c9e4f85a682b5fc356806d/pkg/cmd/server/server.go#L245)
+- Make timeout configurable for retry patching by reusing existing [`--resource-timeout` server flag](https://github.com/vmware-tanzu/velero/blob/d9ca14747925630664c9e4f85a682b5fc356806d/pkg/cmd/server/server.go#L245)

 ## Non Goals
 - Create a new timeout flag
@@ -97,7 +97,7 @@ func RetryOnErrorMaxBackOff(maxDuration time.Duration, fn func() error) error {
 ```

 ## Alternatives Considered
- - Requeuing InProgress backups that is not known by current velero instance to still be in progress as failed (attempted in [#7863](https://github.com/velero-io/velero/pull/7863))
+ - Requeuing InProgress backups that is not known by current velero instance to still be in progress as failed (attempted in [#7863](https://github.com/vmware-tanzu/velero/pull/7863))
    - It was deemed as making backup restore flow hard to enhance for future reconciler updates such as adding cancel or adding parallel backups.

 ## Security Considerations
@@ -107,5 +107,5 @@ None
 Retry should only trigger a restore or backup that is already in progress and not patching successfully by current instance. Prior InProgress backups/restores will not be re-processed and will remain stuck InProgress until there is another velero server (re)start.

 ## Implementation
-There is a past implementation in [#7845](https://github.com/velero-io/velero/pull/7845/) where implementation for this design will be based upon.
+There is a past implementation in [#7845](https://github.com/vmware-tanzu/velero/pull/7845/) where implementation for this design will be based upon.

@@ -6,7 +6,7 @@ New Schedules also create new backup immediately.
 This design allows user to *skip **immediately due** backup run upon unpausing or schedule creation*.

 ## Background
-Currently, the default behavior of schedule when `.Status.LastBackup` is nil or is due immediately after unpausing, a backup will be created. This may not be a desired by all users (https://github.com/velero-io/velero/issues/6517)
+Currently, the default behavior of schedule when `.Status.LastBackup` is nil or is due immediately after unpausing, a backup will be created. This may not be a desired by all users (https://github.com/vmware-tanzu/velero/issues/6517)

 User want ability to skip the first immediately due backup when schedule is unpaused and or created.

@@ -138,12 +138,12 @@ If we instead wanted to use an unique file each time, we could work around the o

 Once the credentials have been serialized, this path will be made available to the plugins.
 Instead of setting the necessary environment variable for the plugin process, the `config` map for the BSL will be modified to include an addiitional entry with the path to the credentials file: `credentialsFile`.
-This will be passed through when [initializing the BSL](https://github.com/velero-io/velero/blob/main/pkg/plugin/velero/object_store.go#L27-L30) and it will be the responsibility of the plugin to use the passed credentials when starting a session.
-For an example of how this would affect the AWS plugin, see [this PR](https://github.com/velero-io/velero-plugin-for-aws/pull/69).
+This will be passed through when [initializing the BSL](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/velero/object_store.go#L27-L30) and it will be the responsibility of the plugin to use the passed credentials when starting a session.
+For an example of how this would affect the AWS plugin, see [this PR](https://github.com/vmware-tanzu/velero-plugin-for-aws/pull/69).

 The restic controllers will also need to be updated to use the correct credentials.
 The BackupStorageLocation for a given PVB/PVR will be fetched and the `Credential` field from that BSL will be serialized.
-The existing setup for the restic commands use the credentials from the environment variables with [some repo provider specific overrides](https://github.com/velero-io/velero/blob/main/pkg/controller/pod_volume_backup_controller.go#L260-L273).
+The existing setup for the restic commands use the credentials from the environment variables with [some repo provider specific overrides](https://github.com/vmware-tanzu/velero/blob/main/pkg/controller/pod_volume_backup_controller.go#L260-L273).
 Instead of relying on the existing environment variables, if there are credentials for a particular BSL, the environment will be specifically created for each `RepoIdentifier`.
 This will use a lot of the existing logic with the exception that it will be modified to work with a serialized secret rather than find the secret file from an environment variable.
 Currently, GCP is the only provider that relies on the existing environment variables with no specific overrides.
@@ -214,16 +214,16 @@ Prior to using any secret for a BSL, it will need to be serialized to disk.
 Using the details in the `Credential` field in the BSL, the contents of the Secret will be read and serialized to a file.
 Each plugin process would still have the same set of environment variables set, however the value used for each of these variables would instead be the path to the serialized secret.

-To set the environment variables for a plugin process, the plugin manager must be modified so that when creating an ObjectStore, we pass in the entire BSL object, rather than [just the provider](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L132-L158).
-The plugin manager currently stores a map of [plugin executables to an associated `RestartableProcess`](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L59-L70).
-New restartable processes are created only [with the executable that the process would run](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L122).
-This could be modified to also take the necessary environment variables so that when [underlying go-plugin process is created](https://github.com/velero-io/velero/blob/main/pkg/plugin/clientmgmt/client_builder.go#L78), these environment variables could be provided and would be set on the plugin process.
+To set the environment variables for a plugin process, the plugin manager must be modified so that when creating an ObjectStore, we pass in the entire BSL object, rather than [just the provider](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L132-L158).
+The plugin manager currently stores a map of [plugin executables to an associated `RestartableProcess`](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L59-L70).
+New restartable processes are created only [with the executable that the process would run](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/manager.go#L122).
+This could be modified to also take the necessary environment variables so that when [underlying go-plugin process is created](https://github.com/vmware-tanzu/velero/blob/main/pkg/plugin/clientmgmt/client_builder.go#L78), these environment variables could be provided and would be set on the plugin process.

 Taking this approach would not require any changes from plugins as the credentials information would be made available to them in the same way.
 However, it is quite a significant change in how we initialize and invoke plugins.

 We would also need to ensure that the restic controllers are updated in the same way so that correct credentials are used (when creating a `ResticRepository` or processing `PodVolumeBackup`/`PodVolumeRestore`).
-This could be achieved by modifying the existing function to [run a restic command](https://github.com/velero-io/velero/blob/main/pkg/restic/repository_manager.go#L237-L290).
+This could be achieved by modifying the existing function to [run a restic command](https://github.com/vmware-tanzu/velero/blob/main/pkg/restic/repository_manager.go#L237-L290).
 This function already sets environment variables for the restic process depending on which storage provider is being used.

 #### Include the details of the secret in `config` map passed to a plugin
@@ -1,7 +1,7 @@
 # Adding Support For VolumeAttributes in Resource Policy
 
 ## Abstract
-Currently [Velero Resource policies](https://velero.io/docs/main/resource-filtering/#creating-resource-policies) are only supporting "Driver" to be filtered for [CSI volume conditions](https://github.com/velero-io/velero/blob/8e23752a6ea83f101bd94a69dcf17f519a805388/internal/resourcepolicies/volume_resources_validator.go#L28)
+Currently [Velero Resource policies](https://velero.io/docs/main/resource-filtering/#creating-resource-policies) are only supporting "Driver" to be filtered for [CSI volume conditions](https://github.com/vmware-tanzu/velero/blob/8e23752a6ea83f101bd94a69dcf17f519a805388/internal/resourcepolicies/volume_resources_validator.go#L28)

 If user want to skip certain CSI volumes based on other volume attributes like protocol or SKU, etc, they can't do it with the current Velero resource policies. It would be convenient if Velero resource policies could be extended to filter on volume attributes along with existing driver filter in the resource policies `conditions` to handle the backup of volumes just by `some specific volumes attributes conditions`.
 
@@ -37,7 +37,7 @@ parameters:
 ```

 ## High-Level Design
-Modifying the existing Resource Policies code for [csiVolumeSource](https://github.com/velero-io/velero/blob/8e23752a6ea83f101bd94a69dcf17f519a805388/internal/resourcepolicies/volume_resources_validator.go#L28C6-L28C22) to add the new `VolumeAttributes` filter for CSI volumes and adding validations in existing [csiCondition](https://github.com/velero-io/velero/blob/8e23752a6ea83f101bd94a69dcf17f519a805388/internal/resourcepolicies/volume_resources.go#L150) to match with volume attributes in the conditions from Resource Policy config map and original persistent volume.
+Modifying the existing Resource Policies code for [csiVolumeSource](https://github.com/vmware-tanzu/velero/blob/8e23752a6ea83f101bd94a69dcf17f519a805388/internal/resourcepolicies/volume_resources_validator.go#L28C6-L28C22) to add the new `VolumeAttributes` filter for CSI volumes and adding validations in existing [csiCondition](https://github.com/vmware-tanzu/velero/blob/8e23752a6ea83f101bd94a69dcf17f519a805388/internal/resourcepolicies/volume_resources.go#L150) to match with volume attributes in the conditions from Resource Policy config map and original persistent volume.

 ## Detailed Design
 The volume resources policies should contain a list of policies which is the combination of conditions and related `action`, when target volumes meet the conditions, the related `action` will take effection.
@@ -3,7 +3,7 @@
 ## Abstract
 To simplify the communication between velero users and developers, this document proposes the `velero debug` command to generate a tarball including the logs needed for debugging.

-Github issue: https://github.com/velero-io/velero/issues/675
+Github issue: https://github.com/vmware-tanzu/velero/issues/675

 ## Background
 Gathering information to troubleshoot a Velero deployment is currently spread across multiple commands, and is not very efficient. Logs for the Velero server itself are accessed via a kubectl logs command, while information on specific backups or restores are accessed via a Velero subcommand. Restic logs are even more complicated to retrieve, since one must gather logs for every instance of the daemonset, and there’s currently no good mechanism to locate which node a particular restic backup ran against.  
@@ -191,7 +191,7 @@ The other VGDP instances will run on nodes, which instance type is `Standard_B4m
 }
 ```

-Velero data mover supports to use different StorageClass to create backupPVC by [design](https://github.com/velero-io/velero/pull/7982).
+Velero data mover supports to use different StorageClass to create backupPVC by [design](https://github.com/vmware-tanzu/velero/pull/7982).

 In this example, if the backup target PVC's StorageClass is `kibishii-storage-class`, its backupPVC should use StorageClass `worker-storagepolicy`. Because the final StorageClass is `worker-storagepolicy`, the backupPod uses the loadAffinity specified by `loadAffinity`'s elements with `StorageClass` field set to `worker-storagepolicy`. backupPod will be assigned to nodes, which instance type is `Standard_B2ms`.

@@ -654,9 +654,9 @@ CLI is not changed.
 [2]: ../volume-snapshot-data-movement/volume-snapshot-data-movement.md
 [3]: ../vgdp-micro-service/vgdp-micro-service.md
 [4]: ../node-agent-concurrency.md
-[5]: https://github.com/velero-io/velero/issues/8955
-[6]: https://github.com/velero-io/velero/issues/8956
-[7]: https://github.com/velero-io/velero/issues/8289
+[5]: https://github.com/vmware-tanzu/velero/issues/8955
+[6]: https://github.com/vmware-tanzu/velero/issues/8956
+[7]: https://github.com/vmware-tanzu/velero/issues/8289
 [8]: https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/
-[9]: https://github.com/velero-io/velero/issues/7725
-[10]: https://github.com/velero-io/velero/issues/8423
+[9]: https://github.com/vmware-tanzu/velero/issues/7725
+[10]: https://github.com/vmware-tanzu/velero/issues/8423
@@ -308,7 +308,7 @@ Backup workflow:
 	}
    ```

- Changes to the Existing [PVC ItemBlockAction plugin](https://github.com/velero-io/velero/blob/512199723ff95d5016b32e91e3bf06b65f57d608/pkg/itemblock/actions/pvc_action.go#L64) (Update the GetRelatedItems function):
+- Changes to the Existing [PVC ItemBlockAction plugin](https://github.com/vmware-tanzu/velero/blob/512199723ff95d5016b32e91e3bf06b65f57d608/pkg/itemblock/actions/pvc_action.go#L64) (Update the GetRelatedItems function):
 ```go
 // Retrieve the VGS label key from the Backup spec.
 	vgsLabelKey := backup.Spec.VolumeGroupSnapshotLabelKey
@@ -338,7 +338,7 @@ Backup workflow:
 	}
 ```

- Updates to [CSI PVC plugin](https://github.com/velero-io/velero/blob/512199723ff95d5016b32e91e3bf06b65f57d608/pkg/backup/actions/csi/pvc_action.go#L200) (Update the Execute method):
+- Updates to [CSI PVC plugin](https://github.com/vmware-tanzu/velero/blob/512199723ff95d5016b32e91e3bf06b65f57d608/pkg/backup/actions/csi/pvc_action.go#L200) (Update the Execute method):
 ```go
 func (p *pvcBackupItemAction) Execute(
    item runtime.Unstructured,
@@ -931,7 +931,7 @@ For 3, Velero leverage on DMs to decide how to save the log, but they will not g
 DMs need to be configured during installation so that they can be installed. Plugin DMs may have their own configuration, for VGDM, the only requirement is to install Velero node-agent.  
 Moreover, the DMP is also required during the installation.  

-From release-1.14, the `github.com/velero-io/velero-plugin-for-csi` repository, which is the Velero CSI plugin, is merged into the `github.com/velero-io/velero` repository.
+From release-1.14, the `github.com/vmware-tanzu/velero-plugin-for-csi` repository, which is the Velero CSI plugin, is merged into the `github.com/vmware-tanzu/velero` repository.
 The reason to merge the CSI plugin is:
 * The VolumeSnapshot data mover depends on the CSI plugin, it's reasonabe to integrate them.
 * This change reduces the Velero deploying complexity.
@@ -44,7 +44,7 @@ When each `RestoreItemAction` `Execute()` call returns, the
 restored. After restoring these items, Velero needs to be able to wait
 for them to be ready before moving on to the next item. Right after
 looping over the additional items at
-https://github.com/velero-io/velero/blob/main/pkg/restore/restore.go#L960-L991
+https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L960-L991

 we still have a reference to the additional items (`GroupResource` and
 namespaced name), as well as a reference to the `RestoreItemAction`
@@ -53,7 +53,7 @@ plugin which required it.
 At this point, if the `RestoreItemActionExecuteOutput`
 `WaitForAdditionalItems` field is set to `true` we need to call a func
 similar to `crdAvailable` which we will call `itemsAvailable`
-https://github.com/velero-io/velero/blob/main/pkg/restore/restore.go#L623
+https://github.com/vmware-tanzu/velero/blob/main/pkg/restore/restore.go#L623
 This func should also be defined within restore.go

 Instead of the one minute CRD timeout, we'll use a timeout specific to
@@ -182,7 +182,7 @@ use an explicit `AreAdditionalItemsReady` func. Since this will break
 backwards compatibility with current `RestoreItemAction` plugins,
 implementation of this feature should wait until Velero plugin
 versioning, as described in
-https://github.com/velero-io/velero/issues/3285 is
+https://github.com/vmware-tanzu/velero/issues/3285 is
 implemented. With plugin versioning in place, existing (non-versioned
 or 1.0-versioned) `RestoreItemAction` plugins which do not define
 `AreAdditionalItemsReady` would be able to coexist with a
@@ -7,7 +7,7 @@ Velero currently treats namespace patterns with glob characters as literal strin

 ## Background

-Requested in [#1874](https://github.com/velero-io/velero/issues/1874) for more flexible namespace selection.
+Requested in [#1874](https://github.com/vmware-tanzu/velero/issues/1874) for more flexible namespace selection.

 ## Goals

@@ -276,9 +276,9 @@ The value for these flags will be stored as annotations.

 #### Handling CA certs

-In anticipation of a new configuration implementation to handle custom CA certs (as per design doc https://github.com/velero-io/velero/blob/main/design/custom-ca-support.md), a new flag `velero storage-location create/set --cacert-file mapStringString` is proposed. It sets the configuration to use for creating a secret containing a custom certificate for an S3 location of a plugin provider. Format is provider:path-to-file.
+In anticipation of a new configuration implementation to handle custom CA certs (as per design doc https://github.com/vmware-tanzu/velero/blob/main/design/custom-ca-support.md), a new flag `velero storage-location create/set --cacert-file mapStringString` is proposed. It sets the configuration to use for creating a secret containing a custom certificate for an S3 location of a plugin provider. Format is provider:path-to-file.

-See discussion https://github.com/velero-io/velero/pull/2259#discussion_r384700723 for more clarification.
+See discussion https://github.com/vmware-tanzu/velero/pull/2259#discussion_r384700723 for more clarification.

 #### Renaming "provider" to "location-plugin"

@@ -344,7 +344,7 @@ Another new behavior that must be added: the server needs to identify when there

 As it is today, a valid VSL would not be required to create backups, unless the backup included a PV.

-To make it easier for the user to identify if their Velero server is ready to create backups or not, a `velero status` command should be added. This issue has been created some time ago for this purpose: https://github.com/velero-io/velero/issues/1094.
+To make it easier for the user to identify if their Velero server is ready to create backups or not, a `velero status` command should be added. This issue has been created some time ago for this purpose: https://github.com/vmware-tanzu/velero/issues/1094.

 ## Alternatives Considered

@@ -8,7 +8,7 @@ The proposed plugin hooks are to be executed only once: pre-backup (before backu

 ### PreBackup and PostBackup Actions

-For the backup,  the sequence of events of Velero backup are the following (these sequence depicted is prior upcoming changes for [upload progress #3533](https://github.com/velero-io/velero/issues/3533) ):
+For the backup,  the sequence of events of Velero backup are the following (these sequence depicted is prior upcoming changes for [upload progress #3533](https://github.com/vmware-tanzu/velero/issues/3533) ):

 ```
 New Backup Request
@@ -40,16 +40,16 @@ New Backup Request
 ```
 These plugin hooks will be invoked:

- PreBackupAction: plugin actions are executed after the backup object is created and validated but before the backup is being processed, more precisely _before_ function [c.backupper.Backup](https://github.com/velero-io/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L590). If the PreBackupActions return an err, the backup object is not processed and the Backup phase will be set as `FailedPreBackupActions`.
+- PreBackupAction: plugin actions are executed after the backup object is created and validated but before the backup is being processed, more precisely _before_ function [c.backupper.Backup](https://github.com/vmware-tanzu/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L590). If the PreBackupActions return an err, the backup object is not processed and the Backup phase will be set as `FailedPreBackupActions`.

- PostBackupAction: plugin actions are executed after the backup is finished and persisted, more precisely _after_ function [c.runBackup](https://github.com/velero-io/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L274).
+- PostBackupAction: plugin actions are executed after the backup is finished and persisted, more precisely _after_ function [c.runBackup](https://github.com/vmware-tanzu/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L274).

 The proposed plugin hooks will execute actions that will have statuses on their own:
 `Backup.Status.PreBackupActionsStatuses` and `Backup.Status.PostBackupActionsStatuses` which will be an array of a proposed struct `ActionStatus` with PluginName, StartTimestamp, CompletionTimestamp and Phase.

 ### PreRestore and PostRestore Actions

-For the restore,  the sequence of events of Velero restore are the following (these sequence depicted is prior upcoming changes for [upload progress #3533](https://github.com/velero-io/velero/issues/3533) ):
+For the restore,  the sequence of events of Velero restore are the following (these sequence depicted is prior upcoming changes for [upload progress #3533](https://github.com/vmware-tanzu/velero/issues/3533) ):
 ```
 New Restore Request
 |--> Validation of the request
@@ -84,9 +84,9 @@ New Restore Request

 These plugin hooks will be invoked:

- PreRestoreAction: plugin actions are executed after the restore object is created and validated and before the backup object is fetched, more precisely in function `runValidatedRestore` _after_ function [info.backupStore.GetBackupVolumeSnapshots](https://github.com/velero-io/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L460). If the PreRestoreActions return an err, the restore object is not processed and the Restore phase will be set a `FailedPreRestoreActions`.
+- PreRestoreAction: plugin actions are executed after the restore object is created and validated and before the backup object is fetched, more precisely in function `runValidatedRestore` _after_ function [info.backupStore.GetBackupVolumeSnapshots](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L460). If the PreRestoreActions return an err, the restore object is not processed and the Restore phase will be set a `FailedPreRestoreActions`.
  
- PostRestoreAction: plugin actions are executed after the restore finishes processing all items and volumes snapshots are restored and logs persisted, more precisely in function `processRestore` _after_ setting [`restore.Status.CompletionTimestamp`](https://github.com/velero-io/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L273).
+- PostRestoreAction: plugin actions are executed after the restore finishes processing all items and volumes snapshots are restored and logs persisted, more precisely in function `processRestore` _after_ setting [`restore.Status.CompletionTimestamp`](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L273).

 The proposed plugin hooks will execute actions that will have statuses on their own:
 `Restore.Status.PreRestoreActionsStatuses` and `Restore.Status.PostRestoreActionsStatuses` which will be an array of a proposed struct `ActionStatus` with PluginName, StartTimestamp, CompletionTimestamp and Phase.
@@ -148,7 +148,7 @@ The PostBackupAction plugin API will resemble the BackupItemAction plugin design
 By this stage, the backup has already been executed, with items backed up and volumes snapshots processed and persisted.
 The `PostBackupAction` interface will only have an `Execute()` method since the plugin will be executed only once per Backup, not per item.

-If there are any PostBackupAction plugins registered, they will be executed after the backup is finished and persisted, more precisely _after_ function [c.runBackup](https://github.com/velero-io/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L274).
+If there are any PostBackupAction plugins registered, they will be executed after the backup is finished and persisted, more precisely _after_ function [c.runBackup](https://github.com/vmware-tanzu/velero/blob/74476db9d791fa91bba0147eac8ec189820adb3d/pkg/controller/backup_controller.go#L274).

 The Velero restore controller package will be modified for `PreRestoreAction` and `PostRestoreAction`.

@@ -156,13 +156,13 @@ The PreRestoreAction plugin API will resemble the RestoreItemAction plugin desig
 It will not receive any resource list items because the restore has not yet been running at that stage.
 In addition, the `PreRestoreAction` interface will only have an `Execute()` method since the plugin will be executed only once per Restore creation, not per item.

-The Velero restore controller will be modified so that if there are any PreRestoreAction plugins registered, they will be executed after the restore object is created and validated and before the backup object is fetched, more precisely in function `runValidatedRestore` _after_ function [info.backupStore.GetBackupVolumeSnapshots](https://github.com/velero-io/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L460). If the PreRestoreActions return an err, the restore object is not processed and the Restore phase will be set a `FailedPreRestoreActions`.
+The Velero restore controller will be modified so that if there are any PreRestoreAction plugins registered, they will be executed after the restore object is created and validated and before the backup object is fetched, more precisely in function `runValidatedRestore` _after_ function [info.backupStore.GetBackupVolumeSnapshots](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L460). If the PreRestoreActions return an err, the restore object is not processed and the Restore phase will be set a `FailedPreRestoreActions`.

 The PostRestoreAction plugin API will resemble the RestoreItemAction plugin design, but with the fundamental difference that it will receive only as input the Velero `Restore` object without any resource list items.
 At this stage, the restore has already been executed.
 The `PostRestoreAction` interface will only have an `Execute()` method since the plugin will be executed only once per Restore, not per item.

-If any PostRestoreAction plugins are registered, they will be executed after the restore finishes processing all items and volumes snapshots are restored and logs persisted, more precisely in function `processRestore` _after_ setting [`restore.Status.CompletionTimestamp`](https://github.com/velero-io/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L273).
+If any PostRestoreAction plugins are registered, they will be executed after the restore finishes processing all items and volumes snapshots are restored and logs persisted, more precisely in function `processRestore` _after_ setting [`restore.Status.CompletionTimestamp`](https://github.com/vmware-tanzu/velero/blob/7c75cd6cf854064c9a454e53ba22cc5881d3f1f0/pkg/controller/restore_controller.go#L273).

 ## Detailed Design

@@ -217,4 +217,4 @@ TBD

 ## Open Issues

-https://github.com/velero-io/velero/issues/21
+https://github.com/vmware-tanzu/velero/issues/21
@@ -1,4 +1,4 @@
-module github.com/velero-io/velero
+module github.com/vmware-tanzu/velero

 go 1.26.0

@@ -24,7 +24,7 @@ import (
 	"os"
 	"text/template"

-	"github.com/velero-io/velero/pkg/cmd/cli/bug"
+	"github.com/vmware-tanzu/velero/pkg/cmd/cli/bug"
 )

 func main() {
@@ -13,7 +13,7 @@ then
 fi

 # GitHub URL which contains the source code archive for the tagged release
-URL=https://github.com/velero-io/velero/archive/$VELERO_VERSION.tar.gz
+URL=https://github.com/vmware-tanzu/velero/archive/$VELERO_VERSION.tar.gz

 # Update brew so we're sure we have the latest Velero formula
 brew update
@@ -100,7 +100,7 @@ rm $DATA_DOCS_DIRECTORY/$NEW_DOCS_TOC.yml && cp $DATA_DOCS_DIRECTORY/$MAIN_BRANC
 if [[ $(uname) == "Darwin" ]]; then
    echo "[OS X] updating version-specific links"
    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "*.md" | xargs sed -i '' "s|https://velero.io/docs/$MAIN_BRANCH|https://velero.io/docs/$VELERO_VERSION|g"
-    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "*.md" | xargs sed -i '' "s|https://github.com/velero-io/velero/blob/$MAIN_BRANCH|https://github.com/velero-io/velero/blob/$VELERO_VERSION|g"
+    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "*.md" | xargs sed -i '' "s|https://github.com/vmware-tanzu/velero/blob/$MAIN_BRANCH|https://github.com/vmware-tanzu/velero/blob/$VELERO_VERSION|g"
    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "_index.md" | xargs sed -i '' "s|version: $MAIN_BRANCH|version: $NEW_DOCS_VERSION|g"

    echo "[OS X] Updating latest version in $CONFIG_FILE"
@@ -121,7 +121,7 @@ ${NEW_DOCS_VERSION}: ${NEW_DOCS_TOC}
 else
    echo "[Linux] updating version-specific links"
    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "*.md" | xargs sed -i'' "s|https://velero.io/docs/$MAIN_BRANCH|https://velero.io/docs/$VELERO_VERSION|g"
-    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "*.md" | xargs sed -i'' "s|https://github.com/velero-io/velero/blob/$MAIN_BRANCH|https://github.com/velero-io/velero/blob/$VELERO_VERSION|g"
+    find $DOCS_DIRECTORY/${NEW_DOCS_VERSION} -type f -name "*.md" | xargs sed -i'' "s|https://github.com/vmware-tanzu/velero/blob/$MAIN_BRANCH|https://github.com/vmware-tanzu/velero/blob/$VELERO_VERSION|g"

    echo "[Linux] Updating latest version in $CONFIG_FILE"
    sed -i'' "s/latest: ${PREVIOUS_DOCS_VERSION}/latest: ${NEW_DOCS_VERSION}/" $CONFIG_FILE
@@ -47,7 +47,7 @@ else
 fi

 echo "${ACTION} goimports"
-output=$(goimports "${MODE}" -local github.com/velero-io/velero ${files})
+output=$(goimports "${MODE}" -local github.com/vmware-tanzu/velero ${files})
 if [[ -n "${output}" ]]; then
  VERIFY_IMPORTS_FAILED=1
  echo "${output}"
@@ -23,7 +23,7 @@ protoc \
  -I pkg/plugin/proto/ \
  -I /usr/include \
  --go_out=pkg/plugin/generated/ \
-  --go_opt=module=github.com/velero-io/velero/pkg/plugin/generated \
+  --go_opt=module=github.com/vmware-tanzu/velero/pkg/plugin/generated \
  --go-grpc_out=pkg/plugin/generated \
  --go-grpc_opt=paths=source_relative \
  --go-grpc_opt=require_unimplemented_servers=false \
@@ -25,8 +25,8 @@ import (
 	corev1api "k8s.io/api/core/v1"
 	kbclient "sigs.k8s.io/controller-runtime/pkg/client"

-	"github.com/velero-io/velero/pkg/util/filesystem"
-	"github.com/velero-io/velero/pkg/util/kube"
+	"github.com/vmware-tanzu/velero/pkg/util/filesystem"
+	"github.com/vmware-tanzu/velero/pkg/util/kube"
 )

 // FileStore defines operations for interacting with credentials
@@ -22,8 +22,8 @@ import (
 	"github.com/stretchr/testify/require"
 	corev1api "k8s.io/api/core/v1"

-	"github.com/velero-io/velero/pkg/builder"
-	velerotest "github.com/velero-io/velero/pkg/test"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	velerotest "github.com/vmware-tanzu/velero/pkg/test"
 )

 func TestNamespacedFileStore(t *testing.T) {
@@ -21,7 +21,7 @@ import (
 	corev1api "k8s.io/api/core/v1"
 	kbclient "sigs.k8s.io/controller-runtime/pkg/client"

-	"github.com/velero-io/velero/pkg/util/kube"
+	"github.com/vmware-tanzu/velero/pkg/util/kube"
 )

 // SecretStore defines operations for interacting with credentials
@@ -29,10 +29,10 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	crclient "sigs.k8s.io/controller-runtime/pkg/client"

-	"github.com/velero-io/velero/pkg/client"
-	plugincommon "github.com/velero-io/velero/pkg/plugin/framework/common"
-	"github.com/velero-io/velero/pkg/plugin/velero"
-	kubeutil "github.com/velero-io/velero/pkg/util/kube"
+	"github.com/vmware-tanzu/velero/pkg/client"
+	plugincommon "github.com/vmware-tanzu/velero/pkg/plugin/framework/common"
+	"github.com/vmware-tanzu/velero/pkg/plugin/velero"
+	kubeutil "github.com/vmware-tanzu/velero/pkg/util/kube"
 )

 // volumeSnapshotContentDeleteItemAction is a restore item action plugin for Velero
@@ -32,11 +32,11 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	crclient "sigs.k8s.io/controller-runtime/pkg/client"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/builder"
-	factorymocks "github.com/velero-io/velero/pkg/client/mocks"
-	"github.com/velero-io/velero/pkg/plugin/velero"
-	velerotest "github.com/velero-io/velero/pkg/test"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	factorymocks "github.com/vmware-tanzu/velero/pkg/client/mocks"
+	"github.com/vmware-tanzu/velero/pkg/plugin/velero"
+	velerotest "github.com/vmware-tanzu/velero/pkg/test"
 )

 // fakeClientWithErrors wraps a real client and injects errors for specific operations.
@@ -19,7 +19,7 @@ package delete
 import (
 	"io"

-	"github.com/velero-io/velero/pkg/plugin/framework"
+	"github.com/vmware-tanzu/velero/pkg/plugin/framework"

 	"github.com/pkg/errors"
 	"github.com/sirupsen/logrus"
@@ -27,11 +27,11 @@ import (
 	"k8s.io/apimachinery/pkg/runtime/schema"
 	"k8s.io/apimachinery/pkg/util/sets"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/archive"
-	"github.com/velero-io/velero/pkg/discovery"
-	"github.com/velero-io/velero/pkg/plugin/velero"
-	"github.com/velero-io/velero/pkg/util/filesystem"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/archive"
+	"github.com/vmware-tanzu/velero/pkg/discovery"
+	"github.com/vmware-tanzu/velero/pkg/plugin/velero"
+	"github.com/vmware-tanzu/velero/pkg/util/filesystem"
 )

 // Context provides the necessary environment to run DeleteItemAction plugins
@@ -29,12 +29,12 @@ import (
 	"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
 	"k8s.io/apimachinery/pkg/runtime"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/builder"
-	"github.com/velero-io/velero/pkg/discovery"
-	"github.com/velero-io/velero/pkg/plugin/velero"
-	"github.com/velero-io/velero/pkg/test"
-	kubeutil "github.com/velero-io/velero/pkg/util/kube"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	"github.com/vmware-tanzu/velero/pkg/discovery"
+	"github.com/vmware-tanzu/velero/pkg/plugin/velero"
+	"github.com/vmware-tanzu/velero/pkg/test"
+	kubeutil "github.com/vmware-tanzu/velero/pkg/util/kube"
 )

 func TestInvokeDeleteItemActionsRunForCorrectItems(t *testing.T) {
@@ -34,13 +34,13 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	"k8s.io/apimachinery/pkg/runtime/schema"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/kuberesource"
-	"github.com/velero-io/velero/pkg/podexec"
-	"github.com/velero-io/velero/pkg/restorehelper"
-	"github.com/velero-io/velero/pkg/util/boolptr"
-	"github.com/velero-io/velero/pkg/util/collections"
-	"github.com/velero-io/velero/pkg/util/kube"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/kuberesource"
+	"github.com/vmware-tanzu/velero/pkg/podexec"
+	"github.com/vmware-tanzu/velero/pkg/restorehelper"
+	"github.com/vmware-tanzu/velero/pkg/util/boolptr"
+	"github.com/vmware-tanzu/velero/pkg/util/collections"
+	"github.com/vmware-tanzu/velero/pkg/util/kube"
 )

 type HookPhase string
@@ -147,7 +147,7 @@ func (i *InitContainerRestoreHookHandler) HandleRestoreHooks(
 		labels := labels.Set(metadata.GetLabels())

 		// Apply the hook according to the target namespace in which the pod will be restored
-		// more details see https://github.com/velero-io/velero/issues/4720
+		// more details see https://github.com/vmware-tanzu/velero/issues/4720
 		if namespaceMapping != nil {
 			if n, ok := namespaceMapping[namespace]; ok {
 				namespace = n
@@ -32,12 +32,12 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	"k8s.io/apimachinery/pkg/runtime/schema"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/builder"
-	"github.com/velero-io/velero/pkg/kuberesource"
-	velerotest "github.com/velero-io/velero/pkg/test"
-	"github.com/velero-io/velero/pkg/util/boolptr"
-	"github.com/velero-io/velero/pkg/util/collections"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	"github.com/vmware-tanzu/velero/pkg/kuberesource"
+	velerotest "github.com/vmware-tanzu/velero/pkg/test"
+	"github.com/vmware-tanzu/velero/pkg/util/boolptr"
+	"github.com/vmware-tanzu/velero/pkg/util/collections"
 )

 func TestHandleHooksSkips(t *testing.T) {
@@ -27,10 +27,10 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	"k8s.io/client-go/tools/cache"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/podexec"
-	"github.com/velero-io/velero/pkg/util/boolptr"
-	"github.com/velero-io/velero/pkg/util/kube"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/podexec"
+	"github.com/vmware-tanzu/velero/pkg/util/boolptr"
+	"github.com/vmware-tanzu/velero/pkg/util/kube"
 )

 type WaitExecHookHandler interface {
@@ -32,10 +32,10 @@ import (
 	"k8s.io/client-go/tools/cache"
 	fcache "k8s.io/client-go/tools/cache/testing"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/builder"
-	velerotest "github.com/velero-io/velero/pkg/test"
-	"github.com/velero-io/velero/pkg/util/boolptr"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	velerotest "github.com/vmware-tanzu/velero/pkg/test"
+	"github.com/vmware-tanzu/velero/pkg/util/boolptr"
 )

 type fakeListWatchFactory struct {
@@ -30,7 +30,7 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	"sigs.k8s.io/yaml"

-	"github.com/velero-io/velero/pkg/util/collections"
+	"github.com/vmware-tanzu/velero/pkg/util/collections"
 )

 const (
@@ -28,7 +28,7 @@ import (
 	corev1api "k8s.io/api/core/v1"
 	crclient "sigs.k8s.io/controller-runtime/pkg/client"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
 )

 type VolumeActionType string
@@ -24,8 +24,8 @@ import (
 	"github.com/stretchr/testify/mock"
 	"github.com/stretchr/testify/require"

-	"github.com/velero-io/velero/pkg/plugin/clientmgmt/process"
-	"github.com/velero-io/velero/pkg/plugin/framework/common"
+	"github.com/vmware-tanzu/velero/pkg/plugin/clientmgmt/process"
+	"github.com/vmware-tanzu/velero/pkg/plugin/framework/common"
 )

 type MockRestartableProcess struct {
@@ -25,7 +25,7 @@ import (
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	"sigs.k8s.io/controller-runtime/pkg/client"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
 )

 // DefaultBackupLocationInfo holds server default backup storage location information
@@ -23,10 +23,10 @@ import (
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	"sigs.k8s.io/controller-runtime/pkg/client/fake"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/builder"
-	velerotest "github.com/velero-io/velero/pkg/test"
-	"github.com/velero-io/velero/pkg/util"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	velerotest "github.com/vmware-tanzu/velero/pkg/test"
+	"github.com/vmware-tanzu/velero/pkg/util"
 )

 func TestIsReadyToValidate(t *testing.T) {
@@ -19,7 +19,7 @@ package velero
 import (
 	"fmt"

-	"github.com/velero-io/velero/pkg/buildinfo"
+	"github.com/vmware-tanzu/velero/pkg/buildinfo"
 )

 // Use Dockerhub as the default registry if the build process didn't supply a registry
@@ -22,7 +22,7 @@ import (

 	"github.com/stretchr/testify/assert"

-	"github.com/velero-io/velero/pkg/buildinfo"
+	"github.com/vmware-tanzu/velero/pkg/buildinfo"
 )

 func TestImageTag(t *testing.T) {
@@ -17,9 +17,9 @@ limitations under the License.
 package velero

 import (
-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	"github.com/velero-io/velero/pkg/plugin/framework"
-	"github.com/velero-io/velero/pkg/plugin/framework/common"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/pkg/plugin/framework"
+	"github.com/vmware-tanzu/velero/pkg/plugin/framework/common"
 )

 type PluginLister interface {
@@ -19,8 +19,8 @@ package volume
 import (
 	"github.com/pkg/errors"

-	"github.com/velero-io/velero/internal/credentials"
-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
+	"github.com/vmware-tanzu/velero/internal/credentials"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
 )

 // UpdateVolumeSnapshotLocationWithCredentialConfig adds the credentials file path to the config
@@ -20,7 +20,7 @@ import (
 	"regexp"
 )

-// it has to have the same value as "github.com/velero-io/velero/pkg/restore".ItemRestoreResultCreated
+// it has to have the same value as "github.com/vmware-tanzu/velero/pkg/restore".ItemRestoreResultCreated
 const itemRestoreResultCreated = "created"

 // RestoredPVCFromRestoredResourceList returns a set of PVCs that were restored from the given restoredResourceList.
@@ -29,13 +29,13 @@ import (
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	kbclient "sigs.k8s.io/controller-runtime/pkg/client"

-	"github.com/velero-io/velero/pkg/label"
+	"github.com/vmware-tanzu/velero/pkg/label"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	velerov2alpha1 "github.com/velero-io/velero/pkg/apis/velero/v2alpha1"
-	"github.com/velero-io/velero/pkg/features"
-	"github.com/velero-io/velero/pkg/itemoperation"
-	"github.com/velero-io/velero/pkg/kuberesource"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	velerov2alpha1 "github.com/vmware-tanzu/velero/pkg/apis/velero/v2alpha1"
+	"github.com/vmware-tanzu/velero/pkg/features"
+	"github.com/vmware-tanzu/velero/pkg/itemoperation"
+	"github.com/vmware-tanzu/velero/pkg/kuberesource"
 )

 type Method string
@@ -31,14 +31,14 @@ import (
 	"k8s.io/apimachinery/pkg/runtime"
 	"k8s.io/apimachinery/pkg/runtime/schema"

-	velerov1api "github.com/velero-io/velero/pkg/apis/velero/v1"
-	velerov2alpha1 "github.com/velero-io/velero/pkg/apis/velero/v2alpha1"
-	"github.com/velero-io/velero/pkg/builder"
-	"github.com/velero-io/velero/pkg/features"
-	"github.com/velero-io/velero/pkg/itemoperation"
-	"github.com/velero-io/velero/pkg/plugin/velero"
-	velerotest "github.com/velero-io/velero/pkg/test"
-	"github.com/velero-io/velero/pkg/util/logging"
+	velerov1api "github.com/vmware-tanzu/velero/pkg/apis/velero/v1"
+	velerov2alpha1 "github.com/vmware-tanzu/velero/pkg/apis/velero/v2alpha1"
+	"github.com/vmware-tanzu/velero/pkg/builder"
+	"github.com/vmware-tanzu/velero/pkg/features"
+	"github.com/vmware-tanzu/velero/pkg/itemoperation"
+	"github.com/vmware-tanzu/velero/pkg/plugin/velero"
+	velerotest "github.com/vmware-tanzu/velero/pkg/test"
+	"github.com/vmware-tanzu/velero/pkg/util/logging"
 )

 func TestGenerateVolumeInfoForSkippedPV(t *testing.T) {
--- a/Show More
+++ b/Show More