Changes between Version 6 and Version 7 of fr/processus

Timestamp:

Mar 23, 2010, 12:21:52 PM (11 years ago)

Author:

laurentj

Comment:

--

fr/processus

@@ -9 +9 @@
 Concrètement, cela se passe ainsi :
 
- - un contributeur propose la correction d'un bug ou autre modification en faisant un patch (fichier diff) attaché à un ticket.
+ - un contributeur propose la correction d'un bug ou autre modification en faisant un patch (fichier diff) attaché à un ticket. Un autre solution est de s'enregistrer sur bitbucket.org, de "forker" le dépot de jelix, de commiter dans son clone, et de proposer ensuite les changements ("pull request"). Dans ce cas, il faut avertir en commentaire dans le ticket pour ce pull.
  - un reviewer relit le code, vérifie que ce code respecte les conventions de codage, que le code n'apporte pas des régressions, que le code est optimisé etc.
  - toute nouvelle fonctionnalité doit en plus avoir l'aval du project leader.
@@ -21 +21 @@
 == Les acteurs ==
 
-Parmis les développeurs de jelix, il y a :
+Parmi les développeurs de jelix, il y a :
 
  * Les contributeurs : ils contribuent en proposant des patchs, des améliorations. Ils ne peuvent accéder en écriture au dépôt principal.
  * Les "commiters" : les contributeurs réguliers, ceux qui ont fait "leur preuves". Ils ont accès en écriture au dépôt principal. Ils font parti de l'équipe de développement du projet.
- * Les "reviewers" : ce sont des commiters qui relisent des patchs avant de donner l'accord d'un commit. Ils connaissent nécessairement le code de jelix en profondeur, ou alors sont expérimentés sur une ou des parties précises de Jelix, et font des reviews uniquement sur les patchs conçernants ces parties.
+ * Les "reviewers" : ce sont des commiters qui relisent des patchs avant de donner l'accord d'un commit. Ils connaissent nécessairement le code de jelix en profondeur, ou alors sont expérimentés sur une ou des parties précises de Jelix, et font des reviews uniquement sur les patchs concernant ces parties.
  * Le "projet leader" : celui qui a le dernier mot :-) Il est le garant du respect de la roadmap, de la cohérence du framework. Il s'assure que les évolutions sont compatibles avec les objectifs premiers du framework (légèreté, performance, simplicité).