Modes de contribution à SPIP

Dimanche 22 avril 2007 — Dernier ajout jeudi 4 février 2010

Ce texte cherche à présenter le minimum nécessaire à une intégration possible dans la communauté SPIP. Mais ce n’est qu’une obligation de moyens, pas de résultat.

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 :
    • imposer PEAR comme prérequis de l’environnement technique pour installer le logiciel [1]
    • opter pour un nommage anglais des fonctions et variables alors que le nomage des fonctions est en français dans SPIP
    • changer la présentation du code (indentation des lignes, espacements autour des opérateurs)
  • 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 :

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.

[1SPIP étant fait pour s’installer partout, et PEAR n’étant pas disponible chez tous les hébergeurs

[2En l’occurrence, augmentation du nombre de niveaux utilisateurs et de niveaux de validation dans la chaine de publication pour répondre à un besoin de l’administration

[3Cette situation a essentiellement marqué le lancement d’Agora

[4Dans la communauté SPIP, les commits sont le premier temps de la documentation : ils s’adressent donc à des utilisateurs et non à des développeurs. Ces derniers peuvent lire le code. Les utilisateurs ont besoin de savoir l’intention du code.

[5Personnifiée est à comprendre : en tant que personne humaine, pas en tant qu’institution ou entreprise

[6À noter : une contribution utilisée par beaucoup de monde finit par être maintenue par ses utilisateurs

[7Ce peut être global, par exemple l’accessibilité, ou ponctuel, par exemple l’affichage des stats

[8Et même si celles-ci sont encore mouvantes, c’est justement l’occasion d’aider à leur stabilisation

Vos témoignages