From d35a411f78b9367a74fe575955dbedebd873c422 Mon Sep 17 00:00:00 2001 From: Bastien Roy Date: Sat, 13 Jan 2024 15:46:19 +0100 Subject: [PATCH] =?UTF-8?q?170=20ajout=20des=20nouvelles=20r=C3=A8gles=20d?= =?UTF-8?q?e=20processus=20de=20MR=20dans=20le=20readMe?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/contributing/contributing.md | 25 ++++++++++++++++-------- docs/contributing/naming.md | 32 ++++++++++++++++++++++++++++--- docs/development/architecture.md | 5 +++-- 3 files changed, 49 insertions(+), 13 deletions(-) diff --git a/docs/contributing/contributing.md b/docs/contributing/contributing.md index 9108b5c..9df730d 100644 --- a/docs/contributing/contributing.md +++ b/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. diff --git a/docs/contributing/naming.md b/docs/contributing/naming.md index c5f8780..029833b 100644 --- a/docs/contributing/naming.md +++ b/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` + \ No newline at end of file diff --git a/docs/development/architecture.md b/docs/development/architecture.md index 9268e47..ff468c7 100644 --- a/docs/development/architecture.md +++ b/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