replace release-tasks.md relative paths with role-handbooks links

CHANGELOG/README.md

@@ -2,4 +2,4 @@
 
 This folder contains release notes for past releases. Changes to this folder in the main branch trigger a GitHub Action that creates release tags and a draft release.
 
-See [release documentation](../docs/release/release-tasks.md) for more information.
+See [release documentation](../docs/release/release-team.md) for more information.

docs/release/release-team-onboarding.md

@@ -25,7 +25,7 @@ through at the beginning of the cycle:
 - Kubernetes SIG membership:
     -  Try to become an official member of the Kubernetes SIG, if possible. More information on the membership and requirements can be found [here](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-team.md#cluster-api-release-team-vs-kuberneteskubernetes-sig-membership).
 - Familiarize yourself with the Release Process:
-    - Review the release [tasks document](../release/release-tasks.md) which explains the responsibilities and tasks for each role within the release team.
+    - Review the release [team roles](../release/release-team.md#team-roles) which explains the responsibilities and tasks for each role within the release team.
 - Check the Release Timeline:
     - Go through the [release timeline](../release/releases) of the release cycle you are involved in (i.e checkout `release-1.6.md` if you are part of the 1.6 cycle release team) to better understand the key milestones and deadlines.
 
@@ -44,7 +44,7 @@ Now, let's dive into the specific onboarding notes for each sub-team below.
 
 - Understand Release Process: 
     - Get to know how project's release process works.
-    - Walk through the [release note generation process](../release/release-tasks.md#create-pr-for-release-notes) and try to generate notes by yourself. This is the most important process the comms team is in charge of.
+    - Walk through the [release note generation process](../release/role-handbooks/communications/README.md#create-pr-for-release-notes) and try to generate notes by yourself. This is the most important process the comms team is in charge of.
     - Familiarize yourself with the release notes tool [code](https://github.com/kubernetes-sigs/cluster-api/tree/main/hack/tools/release). You'll probably need to update this code during the release cycle to cover new cases or add new features.
 - Documentation familiarity:
     - Explore project's documentation and start learning how to update and maintain it.

docs/release/role-handbooks/communications/README.md

@@ -144,7 +144,7 @@ Information can be distributed via:
 * Office hours
 * Release Team meetings
 * Cluster API book
-* [Github Issue](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#communicate-beta-to-providers) (when communicating beta release to providers)
+* [Github Issue](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/role-handbooks/communications/README.md#communicate-beta-to-providers) (when communicating beta release to providers)
 
 Relevant information includes:
 

hack/generate-doctoc.sh

@@ -28,4 +28,4 @@ if [[ -z "$(command -v doctoc)" ]]; then
   exit 0
 fi
 
-doctoc ./CONTRIBUTING.md docs/release/release-tasks.md docs/release/release-team-onboarding.md docs/release/release-team.md docs/proposals
+doctoc ./CONTRIBUTING.md docs/release/release-team-onboarding.md docs/release/release-team.md docs/proposals

hack/tools/release/internal/update_providers/provider_issues.go

@@ -355,7 +355,7 @@ CAPI {{.ReleaseTag}} will be released on **{{.ReleaseDate}}**.
 
 More details of the upcoming schedule can be seen at [CAPI {{.ReleaseTag}} release timeline]({{.ReleaseLink}}).
 
-<!-- [List of CAPI providers](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md#communicate-beta-to-providers) -->
+<!-- [List of CAPI providers](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/role-handbooks/communications/README.md#communicate-beta-to-providers) -->
 <!-- body -->
 `)
 	if err != nil {