diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index c431b8b8c35..0323f2a4d9b 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -3,15 +3,19 @@
 
 If you are unfamiliar with the workflow of contributing to github, you can refer to this [this article](https://github.com/firstcontributions/first-contributions/blob/master/README.md)
 
-## Fork & clone this repository
+## External contributions 
 
-The development should happen in a personal fork, cloned on the local machine.
+If you are not part of the team and want to contribute to this repository, you must fork & clone this repository
 
-## Use development branch
+The development should happen in a personal fork, cloned on the local machine. **Make sure you use signed commits before opening** a pull request.
 
-External contributions should happen against the `development` branch.
+For external contributors, the PRs should be targeted towards the `master` branch. A team responsible will instruct 
+the PR owner to re-target it against another branch, in accordance to internal branches management.
 
-Other branches may be used by the team members in accordance to internal decisions.
+**tl;dr**:
+- fork `elrond-go` and use `master` branch.
+- use signed commits. [docs](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits).
+- open a PR against the `master` branch of `ElrondNetwork/elrond-go`.
 
 ## Use linter
 
@@ -44,3 +48,23 @@ Although the nominal use case looks good, the linter runs without issues, as wel
 Depending on the PR type, there are multiple ways of manual testing the new code:
 - if it only affects an API, a log, or something not critical, one could sync a node with new code on Testnet or Devnet and see if everything works good.
 - if the changes would affect the entire network (consensus, processing, and so on), a local testnet should be started. Also, make sure backwards compatibility is maintained.
+
+## Branches management
+
+Internal Branches/Releases Management (to be checked by both the code owner and the reviewers)
+
+### `elrond-go`
+If the PR is:
+1. a hotfix: it will be targeted towards `master` branch.
+2. a feature:
+   2.1. a small feature (a single PR is needed): targeted towards an `rc` branch.
+   2.2. a big feature (more than one PR is needed): create a feature branch (`feat/...`) that is targeted towards an `rc` branch.
+
+### Satellite projects (`elrond-vm-common`, `elrond-go-core`, and so on)
+If the PR is:
+1. a hotfix: it will be targeted towards `master`/`main` branch.
+2. a feature:
+   2.1. a small feature (a single PR is needed): targeted towards an `rc` branch and create a new tag&release after merging, and reference it in `elrond-go` (if needed).
+   2.2. a big feature:
+   2.2.1. a small satellite PR: targeted towards an `rc` branch. For each change, reference just the commit hash on `elrond-go` and create a tag&pre-release when the `elrond-go` PR is to be merged.
+   2.2.2. a big satellite PR: create a feature branch (`feat/...`) targeted towards an `rc` branch. For each change, reference just the commit hash on `elrond-go` and create a tag&pre-release when the `feat` branch is merged
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 2bad3c860d5..38d32618601 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,9 +1,9 @@
-## Description of the reasoning behind the pull request (what feature was missing / how the problem was manifesting itself / what was the motive behind the refactoring)
+## Reasoning behind the pull request
 - 
 - 
 - 
   
-## Proposed Changes
+## Proposed changes
 - 
 - 
 - 
@@ -12,3 +12,10 @@
 - 
 - 
 - 
+
+## Pre-requisites
+
+Based on the [Contributing Guidelines](CONTRIBUTING.md#branches-management) the PR author and the reviewers must check the following requirements are met:
+- was the PR targeted to the correct branch?
+- if this is a larger feature that probably needs more than one PR, is there a `feat` branch created?
+- if this is a `feat` branch merging, do all satellite projects have a proper tag inside `go.mod`?