add runtime release guidelines in the README and update the PR templa…

…te (#439)

This a PR to update the docs for the runtimes repo with:
- guidelines to summarise key steps involved in <del>Major and
minor</del> releases
- an updated PR template to ensure that contributors adhere to
guidelines

<!-- Remember that you can run `/merge` to enable auto-merge in the PR
-->

<!-- Remember to modify the changelog. If you don't need to modify it,
you can check the following box.
Instead, if you have already modified it, simply delete the following
line. -->

- [x] Does not require a CHANGELOG entry

README.md

@@ -61,6 +61,25 @@ The release process is building all runtimes and then puts them into a release i
 
 The format of [`CHANGELOG.md`](CHANGELOG.md) is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
+## Release guidelines
+
+Here is an overview of the recommended steps.
+
+|Steps |Description |
+|------|------------|
+|0 |Open an [issue](https://github.com/polkadot-fellows/runtimes/issues) for the release in the runtimes repo with the **version number**. |
+|1 |Update **[polkadot-sdk](https://github.com/paritytech/polkadot-sdk?tab=readme-ov-file#-releases)**, if applicable. |
+|2 |Identify and monitor **potential blockers** (old dependencies, pending or failed upgrades). |
+|3 |Identify and include **PRs** with required tests, highlighting the integration tests that have changed. |
+|4 |Identify and communicate all details about **potential breaking changes** (transaction/event/error encoding, polkadot-sdk migrations, XCM and storage format, etc.) or **disruptions**. Make sure to **ping @SBalaguer and @anaelleltd** in your commentary. |
+|5 |Run **[benchmarking](https://github.com/polkadot-fellows/runtimes/blob/main/docs/weight-generation.md)** for changed pallets. |
+|6 |Trigger the release for **final reviews**, making sure to highlight information about all breaking changes or disruptions in the **CHANGELOG entry**. |
+|7 |Create the **[whitelisting proposal (Fellowship)](https://github.com/joepetrowski/opengov-cli)** with contextual information.|
+|8 |Create the **[whitelisted caller referendum (OpenGov)](https://github.com/joepetrowski/opengov-cli)** with contextual information and **instructions for following up** on breaking changes or disruptions. |
+|9 |Close the issue for the release once the referendum is **approved and executed**. |
+|10 |Open an issue for **the next release** in the runtimes repo, if applicable.|
+
+
 ## Communication channels
 
 The Fellowship is using Matrix for communication. Right now there exists two channels:

docs/pull_request_template.md

@@ -0,0 +1,22 @@
+<!--
+Make sure to familiarise yourself with the Runtime release process at https://github.com/polkadot-fellows/runtimes?tab=readme-ov-file#release-process 
+and the Runtime release guidelines at https://github.com/polkadot-fellows/runtimes?tab=readme-ov-file#release-guidelines.
+Use this PR template to streamline the release process, communicate on the changes that you are proposing, and provide a clear course of action for network stakeholders.
+-->
+
+<!---
+1) What kind of changes does this PR introduce?
+Indicate if merging this PR will result in breaking changes (e.g. changes to transaction/event/error encoding, polkadot-sdk migrations, or XCM and storage format) or disruptions for network stakeholders. 
+When submitting a breaking change, please make sure to ping @SBalaguer and @anaelleltd so that they can notify ecosystem teams and builders.
+Otherwise, ignore sections 1 and 2.
+-->
+
+<!---
+2) Who will be impacted by theses changes in practice and how should they follow up on these changes?
+Indicate all network stakeholders (e.g. teams working on parachains or live networks, wallets, UIs, CEXes, or DEXes) that this PR will affect.
+Recommend a course of action (e.g. resources for code refactoring or further reading) for network stakeholders.
+-->
+
+<!-- Remember that you can run `/merge` to enable auto-merge in the PR. -->
+<!-- Remember to modify the changelog and highlight all breaking changes or disruptions. Otherwise, indicate if this is not needed. -->
+- [ ] Does not require a CHANGELOG entry