Ce qu’il ne faut pas faire
Reprenons ci-dessous quelques beaux exemples de mauvaises pratiques dont a fait l’experience le projet Agora :
- coder sans se soucier des principes fondamentaux retenus dans SPIP, notamment :
- coder dans la limite de ses propres besoins, [2] par opposition à un ajout fonctionnel générique qui puisse être librement configuré dans le logiciel ;
- réalisation du code sans visibilité publique des commits, en maintenant un silence radio, et en ne présentant qu’à la dernière étape le produit « fini » [3] ;
- laisser courir un manque persistant de documentation, au niveau du code (commentaires), des commits [4] et sur le Web. Un code non documenté est un code non partagé. S’il n’a pas le mérite d’être suffisamment intéressant pour les développeurs, c’est un code mort.
Comment contribuer ?
Contribuer à SPIP, c’est donner de manière désintéressée et ’personnifiée’ [5].
La contribution doit être « désintéressée »
Contribuer à SPIP, c’est apporter quelque chose qui serve globalement la communauté.
L’appréciation de ce caractère global et générique est parfois difficile. Par exemple, un squelette qui serait bâti avec des n° de rubriques, articles, mots clefs en dur n’est manifestement pas générique. Cependant, l’étude de ses boucles peut rendre un service à la communauté.
Le caractère désintéressé est donc difficile à apprécier.
Et ce n’est même pas le fait que ça a été fait sur du temps non rémunéré qui est le critère déterminant (bien que la défiance vis à vis de l’argent soit une des composantes de la communauté SPIP).
La contribution doit être faite « en personne »
Une contribution ne peut être apportée au nom d’une société commerciale, d’une administration ou d’une institution quelconque. Ni pour mettre en avant l’organisation où travaille la personne qui contribue.
Le caractère personnifié implique la prise en compte des éventuelles incompatibilité de caractères avec la communauté qui rendront difficile la contribution.
La contribution doit être pérenne
Il est essentiel qu’une contribution à SPIP soit pérenne. Pour cela, il faut qu’elle soit d’abord documentée, mais surtout qu’elle soit maintenue à jour [6]
Quelques types de contributions
Développer pour SPIP
Améliorations de celui-ci par :
- du debug
- la fourniture de patch améliorant telle ou telle fonctionnalité [7]
Remontées de bugs
- Trouver des bugs dans SPIP
- Réaliser un ticket
- Vérifier parmi les tickets existants pour les confirmer
Documentation
3 aspects principaux de SPIP peuvent être documentés :
- l’utilisation de SPIP : http://www.spip.net/ et http://www.spip-contrib.net/
- le code de SPIP : http://doc.spip.org/
- les plugins
Plugins
Aujourd’hui, le principal mode de contribution à SPIP passe par les plugins. Pour faire de bons plugins, il faut :
- qu’ils soient utilisables par beaucoup
- qu’ils soient codés en utilisant les API de SPIP [8]
- qu’ils soient codés sans ouvrir des trous de sécurité
- qu’ils soient coder en « forkant » le moins possible le code de SPIP (tout fork étant par essence un point difficile à maintenir dans le temps)
Les plugins sont aussi, de plus en plus, un moyen simple de tester de nouvelles fonctionnalités qui pourraient être intégrées à SPIP.
Dans ce cas, il est préférable de faire :
- un premier commit avec les fichiers originaux de SPIP qui vont être modifiés
- un deuxième commit avec les modification
- et comme toujours, des commentaires donnant l’intention et la documentation à l’attention des utilisateurs
Participer aux apéroSPIP
Ces ateliers décontractés sont des lieux d’échanges où les personnes expérimentées peuvent aider les novices. Voir le site http://www.spip-party.net/ pour les lieux et horaires.