workflow.md

+Architecture du dépôt
+==================
+
+Actuellement, il y a trois branches protégées : 
+- `Production` qui est la version en ligne sur www.cof.ens.fr, seuls les webmasters touchent à ça.
+- `master`, la version la plus récente du projet. De temps en temps, on merge `master` sur `Production`. En théorie, dev.cof.ens.fr suit
+  cette branche.
+- `k-fet` qui suit un chemin parallèle à `master`. Elle est gérée à part car elle correspond à l'appli `kfet` développée bien
+  après le reste par @delobell qui est le seul à connaître bien la codebase pour l'instant.
+
+Pour affecter ces branches, il faut passer par une merge request (cf plus bas). Toute autre branche est gérée librement par les 
+personnes qui travaillent dessus.
+
 Merge requests
-==
+=============
 
 Le fonctionnement des dépots cof-geek se fait par merge requests, qui doivent être reviewées par une personne expérimentée (= Master, cf plus bas) qui n'a pas participé à l'écriture du code. En pratique pour faire une merge request, après avoir cloné le dépot, il faut faire une branche séparée avec `git checkout -b login/ma-branche` où `login` est votre pseudo et `ma-branche` un nom simple décrivant les modifications que vous souhaitez apporter. Ensuite faites vos modifications, puis poussez sur le GitLab. Là vous pouvez aller sur l'interface Web et cliquer sur le bouton "faire une merge request" qui apparaît.
 
-Une fois la merge request effectuée, un Master lira et commentera votre code; c'est à vous de vous assurer de répondre à ses commentaires et de changer votre code en conséquence. Attention une merge request doit être une discussion, ne vous pliez pas juste aux demandes du reviewer sans réfléchir ; faites usage de votre sens critique.
+Une fois la merge request effectuée, un Master lira et commentera votre code. Une merge request est une discussion entre l'auteur du code et le reviewer,
+ne vous pliez pas juste aux demandes du reviewer, votre point de vue compte ! Par ailleurs c'est plus à vous de modifier le code qu'au reviewer, mais cela
+dépend des situations.
+
+En cas de manque de reviewer (exemple : un seul master actif), pour que le travail avance, on peut être contraint de faire des entorses à la règle ci-dessus.
+N'hésitez pas à regarder les merge requests des autres, même  sans être master. C'est mieux que rien et toute remarque constructive est bonne à prendre.
+De plus, c'est une bonne façon de se familiariser avec le code (et pourquoi pas devenir master un jour ;D).
 
 Membres
-==
+========
 
 Il y a trois types de contributeurs à cof-geek.