You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

72 lines
2.8 KiB

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.