From 17e6ff006e9ac54c5e88c2d2ea60fa5a87a86be7 Mon Sep 17 00:00:00 2001
From: Virginia Aponte Garcia <maria-virginia.aponte-garcia@lecnam.net>
Date: Wed, 15 Jan 2025 16:28:12 +0000
Subject: [PATCH] Update DEV.md

---
 DEV.md | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/DEV.md b/DEV.md
index 9597e8b9..28ee18e4 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)
-- 
GitLab