documentation/dev-guide.md

 ---
 title: Developer guide
 ---
+
 # Joining the developers of PASE
 All contributions are welcome. To start coding : 
 - read this developer guide completely for essential information and practices to follow
@@ -53,7 +54,7 @@ Must merge back into:
 `develop` and `main`
 
 Branch naming convention:
-`<issue number>-hotfix-*` (automatically generated through the issue > create branch workflow, see [branching workflow](branching-workflow))
+`<issue number>-hotfix-*` (automatically generated through the issue > create branch workflow, see [branching workflow](#branching-workflow))
 
 ### Feature branches
 > Feature branches are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
@@ -67,7 +68,7 @@ Must merge back into:
 `develop`
 
 Branch naming convention:
-`<issue number>-feature-*` (automatically generated through the issue > create branch workflow, see [branching workflow](branching-workflow))
+`<issue number>-feature-*` (automatically generated through the issue > create branch workflow, see [branching workflow](#branching-workflow))
 
 # Branching workflow
 
@@ -75,6 +76,7 @@ This is the process to create a new branch. It is mandatory to first create an i
 
 ![branching_workflow](uploads/1220d0698239fe6918ab1620d4a6b5c8/branching_workflow.png)
 
+## Issue
 Create an issue with a title containing one of the following keywords in square brackets as prefix : 
 - feature (in a broad sense)
 - hotfix (in a broad sense)
@@ -85,12 +87,48 @@ Example issue title :
 
 Select an issue template (feature request or bug report) and fill all fields as clearly and concisely as possible.
 
+### Assignees
+Assign the issue to people who should or want to work on it.
+
+### Epic 
+Assign the issue to the appropriate Epic (if there is one).
+
+### Milestone
+Assign the issue to the appropriate Milestone (if there is one).
+
+### Weight
+Assign a weight to the issue following the guidelines described in this table:
+
+| Issue weight | Category | Workload - Description                                           |
+|--------------|----------|------------------------------------------------------------------|
+| 1            | Trivial  | < 1h                                                       |
+| 2            | Small    | 1h < but < 1/2 day                                                  |
+| 3            | Medium   | 1/2 day < but < 1 day                                                    |
+| 5            | Large    | > 1 day                                                     |
+| > 5          | Epic     | should be upgraded to an Epic and broken down into smaller issues |
+
+### Labels
+Set the labels, helpful to categorize the issue :
+- who is the lead on the issue ? (helps to clarify responsibility of the work)
+- what theme does the issue pertain to ? (refactoring, data management, a part of the simulation engine, etc.)
+- what is the priority level ?
+
+### Due date
+Set the due date for the issue. Useful to organize work and indicate the level of urgency of the feature or fix.
+
+### Iteration
+Assign the issue to the appropriate Iteration cadence (if there is one).
+
 # Push rules
 
 The online repository has rules on the format of commit messages as well as branch names. 
 
 ## Branch names
-Branch names should always be created from issues, and the Gitlab repository settings are such that their suggested name should always match the branch name push rule.
+Branch names should always be created from Issues, and the Gitlab repository settings are such that their suggested name should always match the branch name push rule.
+When creating a branch, always check that you are branching from the correct source branch (see [Branching strategy : git-flow](#branching-strategy-git-flow))
+
+![image](uploads/58fc4e981b344bd934eae9d4da3f175d/image.png){width=537 height=302}
+
 The branch name rule in the public repository is set with the following regular expression:
 
 `^(main|develop|(\d+)-hotfix-.+|(\d+)-feature-.*|release-v\d+\.\d+\.\d+)$`