Dégraissons l’écureuil

En substance

On se fait plaisir et on dégraisse l’écureil.
Ne tombez pas de votre chaise en lisant la suite, prenez le comme une reflexion et une note d’intention qui doit encore évoluer.

Les listes de diffusion

On maintient l’esprit actuel, SPIP est multilangue, pour chaque langue traduite sur SPIP on trouve une liste de diffusion.

Toutefois il faut penser à les mettre plus en avant sur les sites de la galaxie tel que spip.net.

Documentation

Programmer

Un nouveau projet rejoint la galaxie SPIP, http://programmer.spip.org un site orienté vers les développeurs et les webmestres. La spécificité du site est d’avoir une ligne éditoriale et d’être publiable sous forme de livre.

À chaque version de SPIP, une version figée sera proposée.
Ainsi la documentation sera en adéquation avec la version utilisée par le lecteur.

Toute personne souhaitant participer à la traduction est la bienvenue afin d’offrir à l’ensemble de la communauté un ouvrage de référence accessible pour tous.

Le docteur

doc.spip.org est maintenu car répond à un besoin. Toutefois on constate qu’il répond mal à cette demande.

À terme, il devrait s’orienter plus vers un site de documentation automatique suivant la version SVN tel qu’on peut le voir avec http://www.php.net/manual/

Les points de blocage

Certains d’entre vous, lecteurs, vous avez pu constater certaines tensions au sein de l’équipe. En fait ceci est dù à un petit détail important, nous avons oublié pour certains d’entre nous de prendre le temps de nous faire plaisir.

Cet oubli s’est cristallisé sur certains détails plus ou moins importants qui ont rejailli sur tous. Ce sont surtout des malentendus et des problèmes de communication. Le courriel ne vaut pas toujours un échange dans la vie réelle.

Se faire plaisir, est une chose toute simple mais essentielle dans des projets collaboratifs tel que SPIP. Alors cette année, on repart ensemble mais en gardant sous le coude cette envie.

N’oublions pas, comme dit Marcimat : « Nous avons tous un écureuil dans notre coeur ».

Le cycle de vie

Une des frustrations que nous avons rencontrée a été le cycle de gestation de SPIP 2.0 très long. Nous allons donc essayer d’avoir des mises à jour plus régulières aussi bien pour limiter notre frustration que celle de la communauté. En même temps c’est un bon moyen pour entretenir l’animation autour du projet.

Je vous invite à lire un billet plus complet à ce propos par ici (en cours de publication)

Méthode de travail et Normalisation

Ici suis une liste desorganisée de ce qu’on peut considérer comme volonté de méthode de travail. Bien entendu vous ne trouverez pas de méthode dans l’organisation de cette liste.

Normaliser les noms des fonctions, les fichiers : verbe_infinitif puis objet, on retrouve cette convention entre autre dans le nommage des formulaire CVT.

Les différents éléments devraient être préfixés selon leur natures comme les filtres.

Augmenter la gestion des tests unitaires et automatisés. On voudrait un outil qui parcourt les déclarations des filtres, critères, ... et en s’appuyant sur une convention de nommage génèrerait l’ensemble des combinaisons possibles. Nous avons déjà un jeu de test pour tester des squelettes et un autre plugin qui s’appuie sur une librairie PHP simpletest(). Ces 2 projets sont sur la zone.

« RoadMap »

On utilise le terme de « roadmap » mais n’y voyez pas une notion de planification figée. C’est plutôt une liste des choses que nous pensons nécessaires à faire en fonction des disponibilité de chacun et seront réalisées au fur et à mesure.

Documenter le code avec un formalisme tel que phpdoc, doxygen, javadoc.

Avoir un corps nu et un certain nombre de modules activés par défaut. Cette modularisation doit permettre de faire face à des cycles de développement ayant un rythme différent. Le noyau de SPIP a un cycle plus long que certains modules intégrés.

Un corps nu :-)

Pour le moment nous voyons un noyau réduit offrant un certain nombre de fonctionnalités standardisées tel que :

• Le compilateur
• CVT
• les points d’entrée
• la gestion des meta
• le génie et le cron
• la gestion d’autorisation
• un formalisme sur la rédaction de formulaire
• la logique éditoriale rubrique, article et auteur.
• les filtres de base sur le texte, les dates

Nous rajouterions une partie du code du plugin CFG, pour mieux gérer les meta.
Peut-être la gestion des boucles tableau soit en tant que tel soit avec un formalisme différent.

De l’autre coté nous souhaitons isoler ces modules en plugins :

• les forums
• les statistiques
• les brèves
• l’agenda
• la messagerie interne
• les pétitions
• les documents
• les mots clés
• les logos : pour pouvoir les intégrer dans les documents
• notifications
• filtres images
• syndication / annuaire de sites
• sauvegarde / restauration
• révisions
• vieilles defs

Cette modularisation peut faire peur avec une telle liste mais nous pensons que SPIP est maintenant suffisamment mature et fort pour se permettre cette approche.

Et les utilisateurs ?

Pour les utilisateurs de SPIP rien ne change. D’un coté nous proposerons une version légère et une autre qui proposera une version équivalent à celle actuelle.

Le corps nu sera dédié aux développeurs qui souhaitent personaliser fortement leur SPIP. Nous pensons offrir plus de liberté aux developpeurs et utilisateurs de projets tel que EVA, beespip, ... Vous trouverez plus d’exemple avec les squelettes complets sur la zone.

Le SPIP classique sera le corps nu plus les plugins sortis. En terme fonctionnel l’utilisateur actuel de SPIP ne devrait pas voir de différence, c’est principalement une réorganisation interne.