Fix broken links (polkadot-developers#326)

Author: Sacha Lansky

.github/ISSUE_TEMPLATE/broken-link.yaml

@@ -1,7 +1,7 @@
 name: Broken link
 description: Report a broken link to help us fix them.
 title: "[Broken Link]: "
-labels: ["fixlink"]
+labels: ["broken link"]
 body:
   - type: markdown
     attributes:

.netlify/_redirects_production

@@ -71,6 +71,8 @@
 /docs/en/knowledgebase/learn-substrate/*      /v3/concepts/:splat        301!
 /docs/en/knowledgebase/runtime                /v3/concepts/runtime       301!
 /docs/en/knowledgebase/runtime/               /v3/concepts/runtime       301!
+/docs/en/knowledgebase/runtime/pallets        /v3/runtime/frame#pallets  301!
+/docs/en/knowledgebase/runtime/origin         /v3/runtime/origins        301!
 
 ### Knowledge Base: Runtime Development
 /docs/en/knowledgebase/runtime/fees           /v3/runtime/weights-and-fees  301!

v3/docs/03-runtime/c-metadata/index.mdx

@@ -9,16 +9,16 @@ keywords:
 
 Blockchains that are built on Substrate expose metadata in order to make it easier to interact with
 them. This metadata is separated by the different [pallets](/v3/runtime/frame#pallets) that inform your blockchain.
-For each module, the metadata provides information about the [storage items](../storage),
-[extrinsic calls](../../concepts/extrinsics), [events](../events-and-errors), constants, and errors that are
+For each module, the metadata provides information about the [storage items](/v3/runtime/storage),
+[extrinsic calls](/v3/concepts/extrinsics), [events](/v3/runtime/events-and-errors), constants, and errors that are
 exposed by that module. Substrate automatically generates this metadata for you and makes it
 available through RPC calls.
 
 Since the runtime of a Substrate blockchain is an evolving part of the blockchain's state,
 blockchain metadata is stored on a per-block basis. Be aware that querying the metadata for an older
 block (with an archive node, for example) could result in acquiring out-of-date metadata that is not
 compatible with a blockchain's current state. As described in the
-[Upgrades documentation](../upgrades), developers building on top of Substrate chains can
+[Upgrades documentation](/v3/runtime/upgrades), developers building on top of Substrate chains can
 expect that the metadata for a chain should _only_ change when the chain's
 [runtime `spec_version`](/rustdocs/latest/sp_version/struct.RuntimeVersion.html#structfield.spec_version)
 changes.
@@ -264,7 +264,7 @@ about the module's storage:
 ```
 
 Every storage item that is defined in a pallet will have a corresponding metadata entry. 
-Metadata entries like these are generated from [macros](../macros) using associated types from the [`frame-system`](/rustdocs/latest/frame_system/pallet/trait.Config.html) crate. For example:
+Metadata entries like these are generated from [macros](/v3/runtime/macros) using associated types from the [`frame-system`](/rustdocs/latest/frame_system/pallet/trait.Config.html) crate. For example:
 
 ```rust
 #[pallet::config]
@@ -450,11 +450,11 @@ the [`InvalidSpecName` error](/rustdocs/latest/frame_system/pallet/enum.Error.ht
 
 ### Learn more
 
-- [Storage](../storage)
+- [Storage](/v3/runtime/storage)
 - [SCALE](/v3/advanced/scale-codec)
-- [Macros](../macros)
-- [Events](../events-and-errors)
-- [Extrinsics](../../concepts/extrinsics)
+- [Macros](/v3/runtime/macros)
+- [Events](/v3/runtime/events-and-errors)
+- [Extrinsics](/v3/concepts/extrinsics)
 
 ### References
 

v3/docs/03-runtime/h-weights-and-fees/index.mdx

@@ -59,7 +59,7 @@ You can also use the Transaction Payment pallet to:
 
 * Manage the withdrawal, refund, and deposit of transaction fees using `Config::OnChargeTransaction`.
 
-You can learn more about these configuration traits in the [Transaction Payment](https://substrate.dev/rustdocs/latest/pallet_transaction_payment/index.html) documentation. 
+You can learn more about these configuration traits in the [Transaction Payment](/rustdocs/latest/pallet_transaction_payment/index.html) documentation. 
 
 You should note that transaction fees are withdrawn before the transaction is executed. 
 After the transaction is executed, the transaction weight can be adjusted to reflect the actual resources the transaction used. 
@@ -102,10 +102,10 @@ However, this scenario would be a rare occurrence because the transaction queue
 
 The inclusion fee formula always results in the same fee for the same input. 
 However, weight can be dynamic and—based on how
-[`WeightToFee`](https://substrate.dev/rustdocs/latest/pallet_transaction_payment/pallet/trait.Config.html#associatedtype.WeightToFee)
+[`WeightToFee`](/rustdocs/latest/pallet_transaction_payment/pallet/trait.Config.html#associatedtype.WeightToFee)
 is defined—the final fee can include some degree of variability. 
 
-To account for this variability, the Transaction Payment pallet provides the [`FeeMultiplierUpdate`](https://substrate.dev/rustdocs/latest/pallet_transaction_payment/pallet/trait.Config.html#associatedtype.FeeMultiplierUpdate) configurable parameter.
+To account for this variability, the Transaction Payment pallet provides the [`FeeMultiplierUpdate`](/rustdocs/latest/pallet_transaction_payment/pallet/trait.Config.html#associatedtype.FeeMultiplierUpdate) configurable parameter.
 
 The default update function is inspired by the Polkadot network and implements a targeted adjustment in which a target saturation level of block weight is defined. 
 If the previous block is more saturated, then the fees are slightly increased. 

v3/docs/03-runtime/i-benchmarking/index.mdx

@@ -22,7 +22,7 @@ large overhead such a process would introduce. Instead, Substrate expects benchm
 approximate maximum for the worst case scenario of executing an extrinsic. Users are charged assuming
 this worst case scenario path was taken, and if the extrinsic turns out needing less resources, some of 
 the estimated weight and fees can be returned. This is further explained in the 
-[Transaction Weights and Fees](../weights-and-fees) chapter.
+[Transaction Weights and Fees](/v3/runtime/weights-and-fees) chapter.
 
 ## Why benchmark a pallet
 

v3/how-to-guides/01-basics/g-weights/index.mdx

@@ -15,7 +15,7 @@ difficulty: 1
     "This guide shows a basic procedure for configuring weights. There are more
     advanced methods that suit different use cases. For simple functions with fixed amounts
     of storage reads, this method works well. For any other use cases, see the section 
-    [on weights](../../weights/calculate-fees).
+    [on weights](/how-to-guides/v3/weights/calculate-fees).
     "
 />
 

v3/how-to-guides/02-pallet-design/a-add-contracts-pallet/index.mdx

@@ -47,7 +47,7 @@ difficulty: 1
 
 ### 1. Import the dependencies
 
-Refer to [this guide](../../basics/pallet-integration) to properly include Contracts in your runtime.
+Refer to [this guide](/how-to-guides/v3/basics/pallet-integration) to properly include Contracts in your runtime.
 
 This includes **updating `runtime/Cargo.toml` and `runtime/Cargo.toml`** with:
 

v3/how-to-guides/05-storage-migrations/c-migration-tests/index.mdx

@@ -24,7 +24,7 @@ difficulty: 2
       description:
         `When writing a runtime migration module it is important to test it to avoid any critical issues caused by mangling storage items. This
 		guide provides a walk through of the tests to include for a simple storage migration of a single pallet, using the Nicks pallet
-		migration from the [basic storage migration guide](../basics) as a reference.
+		migration from the [basic storage migration guide](/how-to-guides/v3/storage-migrations/basics) as a reference.
         `,
     },
   ]}
@@ -34,7 +34,7 @@ difficulty: 2
 
 ### 1. Write mock runtime
 
-Refer to [this guide](../../testing/basics) to learn how to set up the dependencies for your test environment.
+Refer to [this guide](/how-to-guides/v3/testing/basics) to learn how to set up the dependencies for your test environment.
 
 ### 2. Specify unit tests