SpipLab:CahierDesChargesSpipV2Modulaire

{{{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->admin@objectif-sciences.com] 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->camps-spip-subscribe@objectif-sciences.com].

- 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->http://asso.objectif-sciences.com/rubrique.php3?id_rubrique=21].

{{{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...}}}