Minor: Update PULL_REQUEST_TEMPLATE.md

[Garandor]

Signed-off-by: Adam Reif [email protected]

Description

I would like everyone to start using the labelling system on our issues and PRs. Later (#661 ) this'll enable us to auto-generate the Changelog. This is an RFC, pls discuss if we should any more mandatory steps @ghzlatarev @Dengjianping

Two goals:

• Clear scope of Milestones and resulting releases (changes only after discussion)
• Easy filtering and resurfacing of related issues

relates to: #600

---

Before we can merge this PR, make sure that all the following items have been checked off.

• [x] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• [x] Added exactly one label from the L- group against this PR
• [x] Added at least one label from the A- and one label from the C- group against either this PR or its associated issue
• [ ] Either this PR or its associated issue is targeted against the current Milestone ( otherwise discuss if it can be added )
• [x] Re-reviewed Files changed in the Github PR explorer.

Situational Notes:

• If adding functonality, write unit tests!
• If importing a new pallet, choose a proper module index for it, and allow it in BaseFilter. Ensure every extrinsic works from front-end. If there's corresponding tool, ensure both work for each other.
• If needed, update our Javascript/Typescript APIs. These APIs are officially used by exchanges or community developers.
• If modifying existing runtime storage items, make sure to implement storage migrations for the runtime and test them with try-runtime. This includes migrations inherited from upstream changes, and you can search the diffs for modifications of #[pallet::storage] items to check for any.
• If runtime changes, need to update the version numbers properly:
  • authoring_version: The version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.
  • spec_version: The version of the runtime specification. A full node will not attempt to use its native runtime in substitute for the on-chain Wasm runtime unless all of spec_name, spec_version, and authoring_version are the same between Wasm and native.
  • impl_version: The version of the implementation of the specification. Nodes are free to ignore this; it serves only as an indication that the code is different; as long as the other two versions are the same then while the actual code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimizations are about the only changes that could be made which would result in only the impl_version changing.
  • transaction_version: The version of the extrinsics interface. This number must be updated in the following circumstances: extrinsic parameters (number, order, or types) have been changed; extrinsics or pallets have been removed; or the pallet order in the construct_runtime! macro or extrinsic order in a pallet has been changed. You can run the metadata_diff.yml workflow for help. If this number is updated, then the spec_version must also be updated
• Verify benchmarks & weights have been updated for any modified runtime logics