_REGLES_DE_COMMIT.txt

Projet  : Plugin insérant des jeux divers et variés dans les articles
Licence : GPL
Auteurs : Patrice Vanneufville
          patrice¡.!vanneufville¡@!laposte¡.!net
         
Voici les règles à suivre avant de commiter des modifications sur
cette branche.

A. Observer le planning de travail.
===================================
	Pour le modifier, proposez-nous vos idées !

       Planning de modification, sans ordre :
          
          1. Prévoir Plusieurs jeux dans une page (a priori OK)
          2. Meilleures CSS
          3. AJAX/jQuery/CVT (en cours)
          4. Traductions (OK avec Salvatore et SPIP v3)
          5. Statistiques des performances et des timings
          6. Sauvegarde des jeux en cours (utilisateurs identifiés)
          7. Notification par mail
          8. Intégrer Hot Potatoes ?
          9. 
          10. D'autres jeux, encore et encore ! 
          
B. Obligation de commenter les commits
======================================

	Si vous envoyez des modifications, il faut toujours les commenter
	de façon "descriptive" et "complète" avec l'option -m ou -F du
	commit SVN.
		
C.  Modification du code
========================

    Cette version peut évoluer. Si vous avez envie de vous
    retrousser les manches, n'hésitez pas. 

    Chaque jeu doit être codé dans un fichier séparé du genre inc/monjeu.php 
    et une signature doit permettre de le retrouver.
    Voir la fonction jeux($chaine) dans jeux_pipelines.php.
    La syntaxe entre les balises <jeux> et </jeux> doit rester unifiée et
    respecter une certaine cohérence.

    Tout le monde à le droit de faire des modifications.
	
    Toutefois, dans un premier temps, il est souhaitable d'avertir  
    les auteurs principaux du projet. Il faut alors, dans le mail, 
    envoyer un patch au format "diff -pu", donner une description 
    défendable du bug corrigé et la manière choisie pour le corriger.
		
    En particulier, il faut bien penser à:
      - décrire le bug que l'on corrige, 
        comment on a choisi de le  corriger,
      - décrire la modification que l'on a faite et pourquoi le
        nouveau code est meilleur que l'ancien (qui n'est certainement 
        pas un code parfait de toute façon)
      - décrire la nouvelle fonction, ce quelle apporte à
        l'utilisateur, les dépendances qu'elle apporte.
  
  
D. Clarté du code
=================

	Il n'y a actuellement pas de règles précises d'écriture correcte du
	code. Il faut juste garder du code indenté (i.e. indenter chaque
	fermeture sur une nouvelle ligne pour les gros blocs), en général,
	suivre la façon dont c'est fait dans les fichiers de base.

	Il faut toujours mettre une chaîne de documentation quand c'est
	possible et quand on le peut documenter le processus/l'algorithme que
	l'on implémente.