You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
73 lines
2.8 KiB
Plaintext
73 lines
2.8 KiB
Plaintext
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.
|