docs: Document the process for merging pull requests

[ximinez]

High Level Overview of Change

Adds instructions to CONTRIBUTING.md for creating and merging PRs, and for creating and merging releases.

Context of Change

This documentation arose out of the post-mortem when creating a new beta took an excessively long time.

Type of Change

• Documentation update

Future Tasks

The PR/merge process may still have room for improvement in the future.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.4%. Comparing base (a39720e) to head (fa786b3).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5010     +/-   ##
=========================================
- Coverage     71.4%   71.4%   -0.0%     
=========================================
  Files          796     796             
  Lines        67042   67042             
  Branches     10863   10867      +4     
=========================================
- Hits         47844   47839      -5     
- Misses       19198   19203      +5     

see 5 files with indirect coverage changes

[intelliot]

i think this is a good improvement over what we currently have, and we can always iterate/modify this with future PRs

[ximinez]

I squashed the previous changes, and marked the PR as no longer a draft. The first commit is the exact set of changes from prior. The second makes a couple of tweaks.

[Bronek]

Minor comments only

[Bronek]

A non-trivial PR will have more than one commit for a good reason, so I wouldn't say "should be usually squashed into one commit"; instead I suggest something like this:

The purpose of separation of a change into commits is not to reflect the history of how the author implemented the change "warts and all", instead it is to describe the change in smaller (yet well-formed) chunks, that make most sense to the reader. For this reason:

• changes should be presented in a logical sequence of a small number (ideally one, for a small change) of commits
• each commit should have a good message to explain a specific aspects of the change.
• every commit should be signed
• every commit should be well-formed (build passing, unit tests passing), as this helps to resolve merge conflicts.

[ximinez]

I agree that there could be good reasons for multiple commits, but I think that should be an uncommon exception. Most PRs should be opened with a single squashed commit.

I have rewritten this part to reflect the rest of your suggestions.

[Bronek]

Thanks for writing this !