Merge branch 'main' into patch-2

.netlify/_redirects

@@ -1,6 +1,6 @@
 # Redirects from what the browser requests to what we serve
 
-/rustdocs                   https://paritytech.github.io/substrate/master/sc_service/ 301!
+/rustdocs                   https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/index.html 301!
 
 /how-to-guides              /reference/                                               301!
 

README.md

@@ -86,8 +86,6 @@ Default localhost port configuration:
 ```env
 GATSBY_WEBSITE_URL=http://localhost:8100
 GATSBY_DOCS_URL=http://localhost:8200
-GATSBY_MARKETPLACE_URL=http://localhost:8300
-GATSBY_CAREERS_URL=https://careers.substrate.io
 ```
 
 **Start development server**

config/menus.js

@@ -1,4 +1,4 @@
-const { MARKETPLACE_URL, WEBSITE_URL, CAREERS_URL } = require('./webConsts.js');
+const { WEBSITE_URL } = require('./webConsts.js');
 
 /* the main menu, ids of items must match
    the submenu's key of this js object */
@@ -58,14 +58,6 @@ const developers = [
     url: 'https://paritytech.github.io/substrate/master/sc_service/',
     id: 'developers.rustdocs',
   },
-  {
-    url: MARKETPLACE_URL,
-    id: 'developers.marketplace',
-  },
-  {
-    url: WEBSITE_URL + '/developers/playground/',
-    id: 'developers.playground',
-  },
   {
     url: WEBSITE_URL + '/developers/smart-contracts/',
     id: 'developers.smart-contracts',
@@ -132,10 +124,6 @@ const opportunities = [
     url: WEBSITE_URL + '/ecosystem/opportunities/grants',
     id: 'ecosystem.opportunities.grants',
   },
-  {
-    url: CAREERS_URL,
-    id: 'ecosystem.opportunities.careers',
-  },
 ];
 
 const resources = [

config/siteMetadata.js

@@ -1,5 +1,5 @@
 const menus = require('./menus.js');
-const { WEBSITE_URL, DOCS_URL, MARKETPLACE_URL, CAREERS_URL } = require('./webConsts.js');
+const { WEBSITE_URL, DOCS_URL } = require('./webConsts.js');
 
 module.exports = {
   menus,
@@ -10,8 +10,6 @@ module.exports = {
   siteUrl: DOCS_URL,
   websiteUrl: WEBSITE_URL,
   docsUrl: DOCS_URL,
-  marketplaceUrl: MARKETPLACE_URL,
-  careersUrl: CAREERS_URL,
   author: 'Parity WebDev/W3F WebOps',
   pressEmail: 'press@parity.io',
   email: 'info@parity.io',

config/webConsts.js

@@ -1,11 +1,7 @@
 const WEBSITE_URL = process.env.GATSBY_WEBSITE_URL;
 const DOCS_URL = process.env.GATSBY_DOCS_URL;
-const MARKETPLACE_URL = process.env.GATSBY_MARKETPLACE_URL;
-const CAREERS_URL = process.env.GATSBY_CAREERS_URL;
 
 module.exports = {
   WEBSITE_URL,
   DOCS_URL,
-  MARKETPLACE_URL,
-  CAREERS_URL,
 };

content/config/nav.yaml

@@ -1,4 +1,5 @@
 menu:
+  - polkadot-sdk
   - quick-start
   - learn
   - install
@@ -10,6 +11,10 @@ menu:
   - reference
   - community
 
+polkadot-sdk:
+  title: Substrate to Polkadot SDK
+  url: /polkadot-sdk/
+
 quick-start:
   title: Quick start
   url: /quick-start/
@@ -84,7 +89,7 @@ install:
       url: /install/developer-tools/
     - title: Troubleshoot Rust issues
       url: /install/troubleshoot-rust-issues/
-  
+
 #design:
  # title: Design
  # url: /design/
@@ -156,7 +161,7 @@ test:
       url: /test/simulate-parachains/
     - title: Check runtime
       url: /test/check-runtime/
-      
+
 deploy:
   title: Deploy
   url: /deploy/

content/locales/en/menus.json

@@ -14,8 +14,6 @@
   "developers.home": "Home",
   "developers.docs": "Docs",
   "developers.rustdocs": "Rust Docs",
-  "developers.marketplace": "Marketplace",
-  "developers.playground": "Playground",
   "developers.smart-contracts": "Smart Contracts",
   "developers.substrate-connect": "Substrate Connect",
   "developers.rococo-network": "Rococo Network",
@@ -32,7 +30,6 @@
 
   "ecosystem.opportunities.hackathons": "Hackathons",
   "ecosystem.opportunities.grants": "Grants",
-  "ecosystem.opportunities.careers": "Careers",
 
   "ecosystem.resources.seminar": "Substrate Seminar",
   "ecosystem.resources.past-seminars": "Past Seminars",

content/md/en/docs/build/build-process.md

@@ -61,7 +61,7 @@ include!(concat!(env!("OUT_DIR"), "/wasm_binary.rs"));
 
 This code includes the compact WebAssembly binary (`WASM_BINARY`) and the uncompressed WebAssembly binary generated by the compiler (`WASM_BINARY_BLOATY`) in its compilation result, and the final executable binary for the project is generated.
 
-At each stage of the build process, the WebAssembly binary is compressed to a smaller and smaller size.
+At each stage of the build process, the WebAssembly binary is compressed to a smaller size than earlier.
 For example, you can compare the sizes of each WebAssembly binary artifact for Polkadot:
 
 ```bash
@@ -118,7 +118,7 @@ For example, you might want to use the native runtime for initial synchronizatio
 To use the native runtime for synchronizing blocks, you can start the node using the `--execution-syncing native` or `--execution-syncing native-else-wasm` command-line option.
 
 For information about using the command-line options to specify an execution strategy for all or specific operations, see [node-template](/reference/command-line-tools/node-template).
-For information about the execution strategy variant, see [ExecutionStrategy](https://paritytech.github.io/substrate/master/sp_state_machine/enum.ExecutionStrategy.html)
+For information about the execution strategy variant, see [ExecutionStrategy](https://paritytech.github.io/substrate/master/sc_cli/arg_enums/enum.ExecutionStrategy.html)
 
 ## Building WebAssembly without a native runtime
 
@@ -127,7 +127,7 @@ After an initial WebAssembly runtime is provided, the blob that represents the W
 In some rare cases, you might want to compile the WebAssembly target without the native runtime.
 For example, if you're testing a WebAssembly runtime to prepare for a forkless upgrade, you might want to compile just the new WebAssembly binary.
 
-Although it's a rare use case, you can use the [build-only-wasm.sh](https://github.com/paritytech/substrate/blob/master/.maintain/build-only-wasm.sh) script to build the `no_std` WebAssembly binary without compiling the native runtime.
+Although it's a rare use case, you can use the [build-only-wasm.sh](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/.maintain/build-only-wasm.sh) script to build the `no_std` WebAssembly binary without compiling the native runtime.
 
 You can also use the `wasm-runtime-overrides` command-line option to load the WebAssembly from the file system.
 
@@ -138,6 +138,6 @@ This option is primarily used for faster compile time when you don't need to upd
 
 ## Where to go next
 
-- [Wasm-builder README](https://github.com/paritytech/substrate/blob/master/utils/wasm-builder/README.md)
+- [Wasm-builder source](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/utils/wasm-builder/src/lib.rs)
 - [Rust compilation options](https://doc.rust-lang.org/cargo/commands/cargo-build.html#compilation-options)
 - [Discussion: Removing the native runtime](https://github.com/paritytech/substrate/issues/10579)

content/md/en/docs/build/genesis-configuration.md

@@ -4,6 +4,11 @@ description:
 keywords:
 ---
 
+<div class="warning">
+  Please refer to the <a href="https://paritytech.github.io/polkadot-sdk/master/frame_support/pallet_macros/attr.genesis_build.html">Rust docs</a> for the most up-to-date documentation on this topic.
+</div>
+
+
 The first block produced by any blockchain is referred to as the genesis block.
 The hash associated with this block is the top-level parent of all blocks produced after that first block.
 
@@ -14,7 +19,7 @@ As you learned in [Chain specification](/build/chain-spec/), the chain specifica
 However, the chain specification doesn't create the storage items that get initialized when you start a node.
 Instead, the storage items are defined in the pallets included in the runtime as described in [Runtime storage](/build/runtime-storage/).
 
-After you create storage items for the runtime, you can choose whether they should be set to some initial value as part of the genesis configuration and included in the genesis block.  
+After you create storage items for the runtime, you can choose whether they should be set to some initial value as part of the genesis configuration and included in the genesis block.
 To specify the storage items that you want to set an initial state for, Substrate provides two specialized FRAME attribute macros.
 
 The macros you can use to initialize storage items as part of the genesis configuration for a chain are:
@@ -115,12 +120,17 @@ All of the `GenesisConfig` types for the pallets that included in the constructi
 The aggregated `RuntimeGenesisConfig` implements the [`BuildStorage`](https://paritytech.github.io/substrate/master/sp_runtime/trait.BuildStorage.html) trait to build all of the initial storage items for the runtime.
 For example, the node template runtime builds storage items for the following pallets that have a `RuntimeGenesisConfig` specified by default:
 
-- [System pallet](#system-pallet)
-- [Aura pallet](#aura-pallet)
-- [Grandpa pallet](#grandpa-pallet)
-- [Balances pallet](#balances-pallet)
-- [TransactionPayment pallet](#transactionpayment-pallet)
-- [Sudo pallet](#sudo-pallet)
+- [Configure a simple storage value](#configure-a-simple-storage-value)
+  - [Configure macros in the pallet](#configure-macros-in-the-pallet)
+  - [Configure the chain specification](#configure-the-chain-specification)
+- [Adding genesis configuration to the runtime](#adding-genesis-configuration-to-the-runtime)
+  - [System pallet](#system-pallet)
+  - [Aura pallet](#aura-pallet)
+  - [Grandpa pallet](#grandpa-pallet)
+  - [Balances pallet](#balances-pallet)
+  - [TransactionPayment pallet](#transactionpayment-pallet)
+  - [Sudo pallet](#sudo-pallet)
+- [Initialize storage items within a pallet](#initialize-storage-items-within-a-pallet)
 
 ### System pallet
 
@@ -193,7 +203,7 @@ pub struct RuntimeGenesisConfig {
 
 Ultimately, the `RuntimeGenesisConfig` is exposed by way of the [`ChainSpec`](https://paritytech.github.io/substrate/master/sc_chain_spec/trait.ChainSpec.html) trait.
 
-For a more complete example of genesis storage configuration for Substrate, see the [chain specification that ships with the Substrate code base](https://github.com/paritytech/substrate/blob/master/bin/node/cli/src/chain_spec.rs).
+For a more complete example of genesis storage configuration for Substrate, see the [chain specification that ships with the Substrate code base](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/bin/node/cli/src/chain_spec.rs).
 
 ## Initialize storage items within a pallet
 

content/md/en/docs/build/origins.md

@@ -5,6 +5,10 @@ keywords:
   - origins
 ---
 
+<div class="warning">
+  Please refer to the <a href="https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/frame_origin/index.html">Rust docs</a> for the most up-to-date documentation on this topic.
+</div>
+
 The runtime origin is used by dispatchable functions to check where a call has come from.
 
 ## Raw origins
@@ -50,7 +54,7 @@ You can look at the source code of the [Sudo module](https://paritytech.github.i
 In addition to the three core origin types, runtime developers are also able to define custom origins.
 These can be used as authorization checks inside functions from specific modules in your runtime, or to define custom access-control logic around the sources of runtime requests.
 
-Customizing origins allows runtime developers to specify valid origins depending on their runtime logic. For example, it may be desirable to restrict access of certain functions to special custom origins and authorize dispatch calls only from members of a [collective](https://github.com/paritytech/substrate/tree/master/frame/collective). The advantage of using custom origins is that it provides runtime developers a way to configure privileged access over dispatch calls to the runtime.
+Customizing origins allows runtime developers to specify valid origins depending on their runtime logic. For example, it may be desirable to restrict access of certain functions to special custom origins and authorize dispatch calls only from members of a [collective](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/collective). The advantage of using custom origins is that it provides runtime developers a way to configure privileged access over dispatch calls to the runtime.
 
 ## Next steps
 
@@ -60,11 +64,11 @@ Customizing origins allows runtime developers to specify valid origins depending
 
 ### Examples
 
-- View the [Sudo pallet](https://github.com/paritytech/substrate/tree/master/frame/sudo) to see how it allows a user to call with `Root` and `Signed` origin.
+- View the [Sudo pallet](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/sudo) to see how it allows a user to call with `Root` and `Signed` origin.
 
-- View the [Timestamp pallet](https://github.com/paritytech/substrate/tree/master/frame/timestamp) to see how it validates an a call with `None` origin.
+- View the [Timestamp pallet](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/timestamp) to see how it validates an a call with `None` origin.
 
-- View the [Collective pallet](https://github.com/paritytech/substrate/tree/master/frame/collective) to see how it constructs a custom `Member` origin.
+- View the [Collective pallet](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/collective) to see how it constructs a custom `Member` origin.
 
 - View our recipe for creating and using a custom origin.
 

content/md/en/docs/build/pallet-coupling.md

@@ -6,6 +6,10 @@ keywords:
   - pallet design
 ---
 
+<div class="warning">
+	 Please refer to the <a href="https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/frame_pallet_coupling/index.html">Rust Docs</a> for the most up-to-date documentation on this topic.
+</div>
+
 The term **coupling** is often used to describe the degree to which two software modules depend on each other.
 For example, in object-oriented programming tight coupling and loose coupling are used to describe the relationship between objects classes:
 
@@ -104,10 +108,10 @@ In general, loose coupling provides more flexibility than tight coupling and is
 It guarantees better maintainability, reusability, and extensibility of your code.
 However, tight coupling can be useful for pallets that are less complex or that have more overlap in methods and types than differences.
 
-In FRAME, there are two pallets that are tightly coupled to [`pallet_treasury`](https://github.com/paritytech/substrate/tree/master/frame/treasury):
+In FRAME, there are two pallets that are tightly coupled to [`pallet_treasury`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/treasury):
 
-- [Bounties pallet](https://github.com/paritytech/substrate/tree/master/frame/bounties)
-- [Tipping pallet](https://github.com/paritytech/substrate/tree/master/frame/tips)
+- [Bounties pallet](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/bounties)
+- [Tipping pallet](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/tips)
 
 As a general rule, the more complex a pallet is, the less desirable it is to tightly couple it.
 This evokes a concept in computer science called [cohesion](<https://en.wikipedia.org/wiki/Cohesion_(computer_science)>), a metric used to examine the overall quality of a software system.

content/md/en/docs/build/randomness.md

@@ -41,7 +41,7 @@ Substrate includes two examples of how to implement the `Randomness` trait in pa
   You should only use this pallet in applications with low security requirements or when testing randomness-consuming applications.
   You shouldn't use this pallet in a production environment.
 
-= The [BABE pallet](https://paritytech.github.io/substrate/master/pallet_babe/index.html) provides randomness by using verifiable random functions.
+- The [BABE pallet](https://paritytech.github.io/substrate/master/pallet_babe/index.html) provides randomness by using verifiable random functions.
 
 This pallet provides production-grade randomness, and is used in Polkadot.
 If you select this pallet as the source of randomness your blockchain must use the blind assignment of blockchain extension ([BABE](/reference/glossary/#blind-assignment-of-blockchain-extension-babe)) slot-based consensus for producing blocks.