diff --git a/DEV.md b/DEV.md
index 9597e8b9db1f558fefbd28d14538788f8d384d46..28ee18e448cbad3ac3247bdb2557c69df600aa56 100644
--- a/DEV.md
+++ b/DEV.md
@@ -1,13 +1,16 @@
-# Contributing
+The fundamental principle is that the MASTER branch must remain compilable at all times and should never contain incomplete developments.
 
-The golden rule is that **MASTER SHOULD COMPILE AT ALL TIME** and does not
-contain in-progress developments.
+Development work on the master branch must be avoided. Instead, each feature or topic should have its own dedicated branch. Developers should create new branches as needed, and all work—including collaborative efforts—should occur within these topic-specific branches.
 
-More precisely, development never happens on master: each topic should have
-its own branch (feel free to create one if needed) and work happens there,
-even when several people are involved.
+Before merging changes into master, ensure that your code:
 
-Once a set of changes (e.g. a new case study) is complete and polished enough
-(comments, adequate identation, no use of generated hypothesis names, etc.),
-you may merge it to master by squashing its commits into meaningful pieces
-(only a few, usually one may be enough) or submit a pull request.
+-   Is complete and thoroughly tested
+-   Contains clear and comprehensive comments
+-   Features proper indentation
+-   Uses descriptive hypothesis names rather than auto-generated ones
+-   Meets all project quality standards
+
+When your changes are ready (such as a completed case study), you have two options:
+
+1.  Submit a pull request for review
+2.  Merge directly into master after squashing your commits into meaningful, well-organized units (typically one or a few commits that clearly represent the changes)