170 ajout des nouvelles règles de processus de MR dans le readMe

docs/contributing/contributing.md

@@ -1,18 +1,31 @@
 # Contributing
 
-You want to contribute to the project ? First, thank you very much! We'll try to do our best to help you getting started.
+You want to contribute to the project ? First, thank you very much! We'll try to do our best to help you getting
+started.
 
-The first step is to clone the project, you can find more information about that in the [getting started guide](../install.md). Once that's done, you can:
+The first step is to clone the project, you can find more information about that in
+the [getting started guide](../install.md). Once that's done, you can:
 
-- choose a task [on the board]() and assign it to yourself - if you don't know which task to do, feel free to reach to us.
+- choose a task [on the board](https://gitlab.com/la-chariotte/la_chariotte/-/boards) and assign it to
+  yourself - if you don't know which task to do, feel free to reach to
+  us.
 - create a new branch **from develop** naming it to reflect what you want to do
 - complete the task, without forgetting to write and run tests (see below)
 - create a Merge Request, containing as many details as possible about what you have done
 
-Then, a maintainer will be able to review your code and suggest improvements/ask questions if necessary. Only maintainers can merge into develop and main.
+Then, a maintainer will be able to review your code and suggest improvements/ask questions if necessary.
+
+If you think your Merge Request should be reviewed by one or more specific person (because their expertise would be
+needed), feel
+free to add them as reviewer of your MR. Only maintainers can merge into develop and main.
 
 Thanks again, and happy coding!
 
+## Merging rules
+
+In order to be merged, your code needs to be reviewed by two maintainers. If you feel the review is taking too long,
+please feel free to send us a message or to ping us on Discord.
+
 ## Working on the frontend
 
 To recompile the files as soon as changes are detected in the scss files.
@@ -60,7 +73,3 @@ build it locally, just run:
 ```bash
 mkdocs serve
 ```
-
-## Merging rules
-
-In order to be merged, your code needs to be reviewed by two maintainers. Don't hesitate to ping us if needed.

docs/contributing/naming.md

@@ -18,7 +18,8 @@ You can add a category if needed, making sure the meaning is easily understandab
 
 Between the category and description, the Gitlab ticket reference related to the branch may be inserted.
 
-The branch description, in English and in kebab-case, must briefly describe the purpose of the branch: the purpose for which it was created without going into detail.
+The branch description, in English and in kebab-case, must briefly describe the purpose of the branch: the purpose for
+which it was created without going into detail.
 
 Good examples:
 
@@ -38,8 +39,10 @@ Bad examples:
 
 Commit names should consist of two parts: a subject and a body (optional).
 
-The subject acts as the title of the commit; it often suffices by itself and should briefly explain the purpose of the commit.
-If needed, the commit message can be enriched with a body that allows for more detailed explanations of what was modified and why (but not how!).
+The subject acts as the title of the commit; it often suffices by itself and should briefly explain the purpose of the
+commit.
+If needed, the commit message can be enriched with a body that allows for more detailed explanations of what was
+modified and why (but not how!).
 
 Commit names must follow these 7 golden rules to ensure uniformity in the project:
 
@@ -64,3 +67,26 @@ Bad examples:
 - `Changing behaviour of X`
 - `add submit button.`
 - `Edit order.py line 72 to improve efficiency by adding recursive algorithm`
+
+## Merge Requests
+
+When creating a merge request, there are a few rules to follow to ensure a global coherence in our merge requests names.
+
+The main rules to follow are the following :
+
+- Begin the merge request name with the number of the ticket surrounded by brackets.
+- Follow with the name of the issue your MR intends to fix.
+- If your MR is not directly related to an issue, describe clearly in a few words the aim of the MR.
+
+Good examples :
+
+- `[152] Add the possibility to order different items`
+- `[245] Rename title of main page`
+- `Corrected typo in page X`
+
+Bad example :
+
+- `112 Add the title to page X`
+- `Corrected some stuff`
+- `[152] Modified the main.py file to correct a typo at line 120 and refacto views to make it a bit clearer`
+ 

docs/development/architecture.md

@@ -3,10 +3,11 @@
 The various Django apps created are:
 
 - ``order``, to manage everything around the orders
-- ``accounts``, to manage account creation. For logging in, logging out, and changing passwords, we use Django’s built-in auth application.
+- ``accounts``, to manage account creation. For logging in, logging out, and changing passwords, we use Django’s
+  built-in auth application.
 - ``mail``, for sending emails.
 
-At the moment, the class diagram is as follows:
+As of today, the class diagram is as follows:
 
 ```mermaid
 classDiagram