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
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.
|
|
|