Fix PRdoc that have been previously drafted with older schema (#2623)

Several PRs started introducing `prdoc` files before the schema was final. This PR fixes those former prdoc to ensure that pass the check and comply with the current prdoc schema. --------- Co-authored-by: command-bot <>
2026-06-12 14:41:11 +00:00 · 2023-12-05 17:29:13 +01:00
parent 20eaad9d48
commit 5dd6a4ba47
10 changed files with 35 additions and 45 deletions
@@ -6,9 +6,9 @@ doc:
      Changed approval-voting, approval-distribution to send all messages tranche0 assignments in one message.
      This required:
      * A new parachains_db version.
-      * A new validation protocol to support the new message types. 
+      * A new validation protocol to support the new message types.
      The new logic will be disabled and will be enabled at a later date after all validators have upgraded.
-   
+
 migrations:
  db:
    - name: Parachains database change from v3 to v4.
@@ -18,6 +18,5 @@ migrations:

 crates:
  - name: "polkadot"
-    semver: patch

 host_functions: []
@@ -1,17 +1,17 @@
 title: Use the `Message Queue` Pallet for DMP and XCMP dispatch queueing

 doc:
-  - audience: Parachain Dev
+  - audience: Runtime Dev
    description: Replaces the queueing capabilities of the `DMP and `XCMP-Queue` pallet for incoming messages with the `MessageQueue` pallet. This simplifies the code and improves security.

 migrations:
  runtime:
    -
-      pallet: "cumulus_pallet_dmp_queue"
+      reference: cumulus_pallet_dmp_queue
      description: "Messages from the DMP dispatch queue will be moved over to the MQ pallet via `on_initialize`. This happens over multiple blocks and emits a `Completed` event at the end. The pallet can be un-deployed and deleted afterwards. Note that the migration reverses the order of messages, which should be acceptable as a one-off."

 crates:
-  - name: "cumulus_pallet_xcmp_queue"
+  - name: cumulus_pallet_xcmp_queue
    note: Pallet config must be altered according to the MR description.

 host_functions: []
@@ -4,25 +4,26 @@
 title: Supporting paged rewards allowing all nominators to be rewarded

 doc:
-  - audience: Validator
+  - audience: Node Operator
    description: |
      We used to clip top `MaxNominatorRewardedPerValidator` nominators by stake that are eligible for staking reward.
      This was done to limit computation cost of paying out rewards. This PR introduces paging to reward payouts,
      meaning we still clip nominators upto MaxExposurePageSize per page and there could be multiple pages of rewards to
      be paid out. Validators get commission pro-rata to the amount of reward that is paid out for the page.

-    notes:
-      - payout_stakers should be called multiple times, once for each page of nominators.
-      - payout_stakers_by_page can be used to pay out rewards for a specific page.
-      - Some old non-paged era storage items are deprecated, and can be removed in a future upgrade.
+      notes:
+        - payout_stakers should be called multiple times, once for each page of nominators.
+        - payout_stakers_by_page can be used to pay out rewards for a specific page.
+        - Some old non-paged era storage items are deprecated, and can be removed in a future upgrade.

 migrations:
  db: []

  runtime:
-    - { pallet: "pallet-staking", description: "v14: Migration of era exposure storage items to paged exposures."}
+    - reference: pallet-staking
+      description: "v14: Migration of era exposure storage items to paged exposures."

 crates:
  - name: pallet-staking

-host_functions: []
+host_functions: []
@@ -1,7 +1,7 @@
 title: Introduce state decoding check after runtime upgrades.

 doc:
-  - audience: Core Dev
+  - audience: Runtime Dev
    description: |
      Adds a check to the try-runtime logic that will verify that all pallet on-chain storage still decodes. This can help to spot missing migrations before they become a problem. The check is enabled as soon as the `--checks` option of the `try-runtime` CLI is not `None`.

@@ -10,10 +10,8 @@ migrations:

  runtime: []

-crates: 
+crates:
  - name: frame-support
-    semver: minor
  - name: frame-support-procedural
-    semver: minor

 host_functions: []
@@ -1,10 +1,10 @@
 title: Adds syntax for marking calls feeless

 doc:
-  - audience: Core Dev
+  - audience: Runtime Dev
    description: |
      1. Adds an attribute `#[pallet::feeless_if]` that can be optionally attached to a `pallet::call`.
-      2. Adds a signed extension SkipCheckIfFeeless<T: SignedExtension> that wraps a transaction 
+      2. Adds a signed extension SkipCheckIfFeeless<T: SignedExtension> that wraps a transaction
      payment processor to potentially skip payment fees for such calls.
      Note that both the attribute and the signed extension are needed to make the call feeless.

@@ -14,17 +14,11 @@ migrations:
  runtime: []

 crates:
-  - name: "frame-support-procedural"
-    semver: minor
-  - name: "pallet-skip-feeless-payment"
-    semver: major
-  - pallet-example-kitchensink
-    semver: patch
-  - kitchensink-runtime
-    semver: major
-  - node-testing
-    semver: patch
-  - node-cli
-    semver: patch
+  - name: frame-support-procedural
+  - name: pallet-skip-feeless-payment
+  - name: pallet-example-kitchensink
+  - name: kitchensink-runtime
+  - name: node-testing
+  - name: node-cli

 host_functions: []
@@ -1,15 +1,12 @@
 title: "Contracts: Add XCM traits to interface with contracts"

 doc:
-  - audience: Core Dev
+  - audience: Runtime Dev
    description: |
      We are introducing a new set of `XcmController` traits in `pallet-xcm`.
-      These traits extract functionality from `pallet-xcm` and provide high-level interaction with XCM. 
+      These traits extract functionality from `pallet-xcm` and provide high-level interaction with XCM.
      They enable other pallets, like `pallet_contracts`, to rely on these traits instead of tight coupling to `pallet-xcm` itself.

 crates:
-    - name: "pallet-xcm"
-      semver: patch
-    - name: "xcm-executor"
-      semver: patch
-
+  - name: pallet-xcm
+  - name: xcm-executor
@@ -4,14 +4,16 @@
 title: Add a builder pattern to create XCM programs

 doc:
-  - audience: Core Dev
+  - audience: Runtime Dev
    description: |
      XCMs can now be built using a builder pattern like so:
+      ```
      Xcm::builder()
        .withdraw_asset(assets)
        .buy_execution(fees, weight_limit)
        .deposit_asset(assets, beneficiary)
        .build();
+      ```

 migrations:
  db: []
@@ -1,12 +1,12 @@
 title: Cleanup XCMP `QueueConfigData`

 doc:
-  - audience: Parachain Dev
+  - audience: Runtime Dev
    description: Removes obsolete fields from the `QueueConfigData` structure. For the remaining fields, if they use the old defaults, we replace them with the new defaults.

 migrations:
  runtime:
-    - pallet: "cumulus_pallet_xcmp_queue"
+    - reference: cumulus_pallet_xcmp_queue
      description: "v4: Removes obsolete fields from the `QueueConfigData` structure. For the remaining fields, if they use the old defaults, we replace them with the new defaults."

 crates: []
@@ -1,7 +1,7 @@
-title: Add sudo::remove_key
+title: Add `sudo::remove_key`

 doc:
-  - audience: Core Dev
+  - audience: Runtime User
    description: |
      Pallet `Sudo` now has the ability to remove the sudo key via `remove_key`. This is a less-invasive way of rendering the sudo pallet useless without needing a code upgrade.

@@ -12,6 +12,5 @@ migrations:

 crates:
  - name: pallet-sudo
-    semver: minor

 host_functions: []
@@ -4,7 +4,7 @@
 title: Different builder pattern constructors for XCM

 doc:
-  - audience: Core Dev
+  - audience: Runtime Dev
    description: |
      The `builder()` constructor for XCM programs now only allows building messages that pay for fees,
      i.e. messages that would pass the `AllowTopLevelPaidExecutionFrom` barrier.