feat(chained_prs): add description on chained PRs

Signed-off-by: Daniel Oliveira <[email protected]>

source/development/contributing.rst

@@ -118,7 +118,9 @@ development directly on it. Follow these steps:
 4. `Create a PR <https://docs.github.com/en/pull-requests/
    collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-
    requests/creating-a-pull-request>`_ targeting the original repository's
-   ``main`` branch;
+   ``main`` branch. In case the PR introduces a large set of modifications, to
+   facilitate the review process, it is recommended to split it into multiple
+   smaller PRs (i.e., :ref:`a chain of PRs <chain_of_prs>`).
 5. Patiently wait for reviews and be engaged when they arrive:
 
     * participate in the discussion with **reviewers**;
@@ -136,6 +138,44 @@ development directly on it. Follow these steps:
     * if the **reviewers** are taking too long, try contacting the :term:`PR`
       assignee.
 
+.. _chain_of_prs:
+
+Chain of PRs
+############
+
+Code reviews are typically a difficult and time-consuming process. To
+facilitate the reviewer's work, contributors should try to split their PRs into
+smaller ones if they feel that the PR introduces a large set of modifications.
+Nevertheless, the assignee of the PR is the ultimate responsible for
+understanding if the PR is too large and asking the contributor to split the
+monolithic PR into smaller ones that create a chain of PRs composed by
+logically-separated set of PRs.
+
+To create a chain of PRs, a contributor should follow this process:
+
+* create a topic branch from the ``main`` branch and called it
+  ``wip/<name>`` (where ``<name>`` is a short description of the feature,
+  subsystem, or functionality being developed);
+* this ``wip/<name>`` should be the base branch of the overall feature to be
+  submitted. For example, it can a skeleton PR that only contains the
+  infrastructure of the new functionality;
+* submit this base branch as the first PR of the chain and mention on the PR
+  description that it is the base branch of a chain of PRs;
+* continue to introduce the remaining parts of the PR as pieces of a one-row
+  puzzle, meaning that each PR should be logically self-contained and dependent
+  on the previous one. Therefore, while creating a new PR (e.g.,
+  ``wip/subfeat1``) make sure that the correct base branch is selected. For
+  example, while ``wip/base_feat`` targets the ``main`` branch, the base branch
+  of ``wip/subfeat1`` should be effectively ``wip/base_feat``. The below
+  diagram provides a visual representation of the chain of PRs.
+* as each PR is merged, the github will automatically update the base branch of
+  the next PR in the chain. The assigned should merge the ``wip/<name>`` branch
+  after all the PRs in the chain are merged.
+
+.. code-block:: none
+
+  [main] <- [wip/base_feat] <- [wip/subfeat1] <- [wip/subfeat2]
+
 Review Assignment
 *****************