• UCL : http://www.sgsi.ucl.ac.be/bonnecond/Bonne_cond.html
• FSA : http://www.fsa.ucl.ac.be/IFSA/conduite.html
• Netiquette : http://www.sri.ucl.ac.be/rfc1855.fr.html
• SRI : http://www.sri.ucl.ac.be/netetiq.html
• Règlement UCL : http://www.uclouvain.be/11212.html

Merci zefredz

Si vous utilisez NVU, Daniel Glazman fait un petit appel au feedback

"WANTED ! I need more peer reviewers for Composer... I just cannot put everything on Neil's and timeless's shoulders, that's impossible. If you have spare cycles and are willing to help reviewing XUL, JS, XBL and CSS, please add a comment to this post with your bugmail address so I can send you requests. Thanks!"

Réponse à Laurent Jouanneau

J'utilise phpdoc pour générer la documentation de réference de Jelix. Globalement, il répond à mes besoins sur le papier. Cependant, il a des défauts :

"J'ai bien essayé de regarder ailleurs, mais le seul truc que j'ai trouvé, et qui soit à la hauteur (et relativement compatible) au niveau des tags, est doxygen (mais difficilement personnalisable, pas de templates...)."

Zefredz, mon collègue me dit souvent du bien de doxygen. Moi avec phpDocumentor intégré à Zend Studio et et au site web de PEAR, je me pose pas trop la question.

"Mais peut-être qu'il y a un développeur qui s'ennuie dans le coin ? :-)" "En attendant, j'ai décidé de rester avec phpdoc et de poster des bugs sur le site du projet... :-|"

Pour moi c'est toujours la plus sage des décisions.

Dans l'urgence et le cours terme, il faut du from scratch ou du "modification/adaptation personnelle" mais dans tous les cas, faire part au projet initial de "ce qui m'a manqué" et de "comment je le ferai".

Arriver à ne pas être frustré quand une idée n'est pas recue du premier coup.

Bien sur de l'autre coté, pas toujours facile pour le développeur du projet déjà communautarisé de se laisser remmetre en question par un qui n'a encore rien fait ...

C'est fou ce que le problème des codes "partagés" opensource ou autre est beaucoup plus souvent social que technique.

Foutu ego.

Il est sur qu'un dev X a une mission Y. et faire un code en pensant à la mission Z de W n'est pas budgetisé....