Non aux brevets logiciels

SpipLab

CahierDesChargesSpipV2Modulaire

PagePrincipale :: DerniersChangements :: Vous êtes 38.103.63.16 (Connexion)

Avertissement :

Ce document est ouvert à la rédaction à tous les développeurs de la Communauté du logiciel libre SPIP qui désirent participer. Il a une valeur uniquement technique.

-  Les informaticiens qui désirent encadrer les Camps SPIP peuvent me contacter sur cette adresse et tous ceux qui désirent participer aux travaux de préparation sans pour autant encadrer les Camps peuvent le faire en s’inscrivant sur la liste de discussion.

-  Les personnes qui désirent s’inscrire sur les Camps en tant que participant peuvent se rendre sur le catalogue en ligne des Camps SPIP.

INTRODUCTION

Allons ensemble vers la modularité

La communauté des informaticiens travaillant sur et avec SPIP est aujourd’hui constituée de plusieurs groupes plus ou moins reliés et qui utilisent chacun une version différente de SPIP. Le groupe principal et très largement majoritaire est bien entendu celui qui utilise la version SPIP "pure". Aujourd’hui, certaines des versions dérivées de SPIP ne sont plus compatibles avec la version officielle, ce qui bride de nombreux développements possibles et limite l’apport de nouvelles fonctionnalités.

La version modulaire de SPIP, pressentie par beaucoup comme une solution intéressante sur le plan de son utilisation, serait également le moyen de permettre à chaque sous-communauté d’apporter ses contributions en conservant constamment la même version unique et officielle de SPIP.

Des règles de contribution

Le cahier des charges, outre l’énumération de ce que doit être le noyau d’une version modulaire et de la manière dont devraient être organisés les modules entre eux, peut également être l’occasion de définir des règles de contribution sous la forme de modules à l’instar des règles qui existent déjà pour la rédaction des squelettes (modèles d’affichage des pages des sites gérés par SPIP). C’est tout l’enjeu d’une maintenance facilitée par la possibilité pour quiconque de faire une intervention sur un module et de proposer la version améliorée aux mainteneurs du logiciel pour validation.

Passer le seuil

Afin de permettre un passage suffisamment massif à la version modulaire et ainsi mettre de côté tout risque de bifurcation entre diverses versions qui risquent d’apparaître en concurrence, l’association Objectif Sciences, son personnel d’éducation et tous les jeunes participants à ses activités, se proposent de participer au travail de programmation nécessaire. En plus du plaisir que cela procurera aux jeunes férus d’informatique et aux membres de l’association, cela permettra surtout de produire un minimum de 6 modules compatibles avec le cahier des charges de la version officielle de SPIP.

Un seul logiciel pour tout le monde

Certaines sous-communautés sont très exigeantes et demandent des solutions pointues qui ne peuvent par exemple être hébergées que sur des serveurs dédiés. Ces sous-communautés demandent un logiciel à part. La réponse de ce cahier des charges est négative pour la simple et bonne raison que la version modulaire vient justement à point nommé pour permettre une fusion de toutes les versions existantes. Qui peut le plus peut le moins et le cahier des charges vise donc à définir un logiciel dont l’installation serait paramétrable en fonction des besoins de l’utilisateur. Le choix d’une utilisation sur un serveur dédié, sur un espace mutualisé riche en services ou encore sur un espace d’hébergement gratuit et donc pauvre en services doit pouvoir relever de ce type de paramétrage à l’installation.

PARTIE I : LES ATTENTES

Du point de vue des utilisateurs

Du point de vue des webmestres

Du point de vue des prestataires

Du point de vue des commanditaires auprès de prestataires

Du point de vue des développeurs

PARTIE II : SPECIFICATIONS

Le Noyau

Si l’on "sort" tout le contenu du SPIP actuel, module par module, ce qui reste serait le noyau ( ?) et à cela devrait être ajouté un moteur de modules.

Liste des fonctionnalités en dehors de la question des modules

Toutes fonctionnalités confondues, y compris les nouveautés telles que traduction automatique ou super-newsletter…

Liste des modules et des fonctionnalités couverte(s)

Module Fonctionnalité(s) couvertes
Installation Type d’hébergement, ajouts de modules…
Configuration Configuration minimale des droits et des fonctionnalités et du rubriquage…
Rédaction Gestion de tout ce qui a trait à la rédaction des articles, brèves...
Traduction Gestion de tout ce qui a trait à la traduction à la manière de PoEdit* (mini-mémoire de traduction) pas seulement les fichier de langue mais aussi le contenu du site

Détails de chaque module

Organisation des modules les uns par rapport aux autres

PARTIE III : REGLES DE PROGRAMMATION DES MODULES

PARTIE IV : PLAN DE PROGRAMMATION

Plan général

Noyau

Module 1

Module 2

etc...