CONTRIBUTING.md: Add design reviews section

New big features need to be documented properly.
Adding a design review (DR) as a requirement for every new feature will
make sure that the contributor gets the proper guidance from the more
experienced prplMesh maintainers / contributors. It will save us from
merging bad code since "its already there", and allow for better
quality.
Add a section which explains the requirement for design reviews to the
CONTRIBUTING.md file.

Signed-off-by: Tomer Eliyahu <[email protected]>

CONTRIBUTING.md

@@ -276,6 +276,27 @@ If a PR is marked "don't merge" and it becomes ready (i.e. you did the necessary
 
 A good example of a pull request with review, discussion, and several iterations is https://github.com/prplfoundation/prplMesh/pull/831.
 
+### Design reviews
+
+Every new feature / big change should be accompanied with a design review (DR).
+It makes sure that the contributor gets the proper guidance from the more experienced prplMesh maintainers / contributors, saves us from merging bad code "since its already there", and in general allows for better quality.
+
+**Do not start working on a feature before a DR is approved by the community**. This will lead to potentially wasted effort, since you might go in the wrong direction, or in a worse scenario - "bad" code getting into our codebase, which we would really like to avoid.
+> Tip - if you are not sure if a certain feature / bug fix requires a DR - ask first in #prplmesh-dev channel in slack.
+
+The DR document shall be written in Markdown (.md) format, and will be the first commit in the Pull Request, under the documentation folder. For example, a DR which changes the autoconfiguration flow should be added to `documentation/flows/autoconfig`.
+
+A good DR document normally includes an introduction, problem statement, detailed description and references sections.
+As an example, let us assume we are implementing station measurements flow in prplmesh.
+The introduction section should give a first reader a basic overview of the feature. This of it as an "abstract" of a scientific paper - so in this section we will desribe what the station measurements flow, with references to the EasyMesh specification.
+
+The problem statement should explain the current state of the feature in prplMesh. In our example, the station measurements are implemented in vendor specific messages since this was used by prplMesh before the EasyMesh standard. The problem statement will explain that the current vendor specific implementation has to change to use EasyMesh messages so that non-prplMesh controllers can be supported by prplMesh.
+
+The detailed description section should dive into details and must include UML diagram\[s\] of the current prplMesh state, and the proposed solution\[s\].
+> Tip - use [plantuml](https://plantuml.com/) format to describe UML diagrams.
+
+The references section should include a list of all references used in the DR, with hyper links to where each reference can be viewed.
+
 ### Testing
 
 Some changes are riskier than others, since they may break existing functionality which is not yet covered by prplMesh CI.