Minor: Update PULL_REQUEST_TEMPLATE.md

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,16 +1,6 @@
-<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
-v                               ✰  Thanks for creating a PR! ✰
-v    Before hitting that submit button please review the checkboxes.
-v    If a checkbox is n/a - please still include it but + a little note why
-☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->
-
 ## Description
 
-<!-- Add a description of the changes that this PR introduces and the files that are the most critical to review.
-Please commit refactors and minor intermediate (doc) changes on your PR with the `[no ci]` keyword to skip meaningless runs of the full CI pipeline.
--->
-
-closes: #XXXX
+relates to OR closes: #XXXX
 
 ---
 
@@ -19,16 +9,18 @@ checked off. If any of the checklist items are not applicable, please leave them
 write a little note why.
 
 - [ ] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
-- [ ] Wrote unit tests.
-- [ ] Updated relevant documentation in the code.
 - [ ] Added **one** line describing your change in `<branch>/CHANGELOG.md`
 - [ ] Re-reviewed `Files changed` in the Github PR explorer.
-- [ ] If runtime changes, need to update the version numbers properly:
+
+
+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
-- [ ] 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.
+   * `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