Modèle communautaire de modélisation océanique développé par un consortium européen, le projet NEMO a construit son environnement numérique avec les outils collaboratifs usuels organisant le développement d'un code: un site internet, une forge de développement logiciel associant un dépôt versionné des sources à une plateforme de gestion de projet, accompagné de listes de diffusion.
Cette architecture mise en place à cette époque s'est révélée tout à fait pertinente sur le long terme, les outils d'un projet collaboratif se sont étoffés avec le temps accompagnant un mouvement global d'essor et d'ouverture du développement logiciel, mais les composantes de base sont restées les mêmes. Néanmoins l'ensemble avait plusieurs défauts originels et s'est peu à peu déprécié avec le temps par manque de ressources dédiées pour faire évoluer les systèmes d'information et les services offerts, mais également pour revoir les choix de configuration s'étant révélés à l'usage peu en adéquation avec l'organisation du projet et les nouveaux usages en cours dans le champ du développement logiciel.
Le présent rapport se propose de détailler les orientations prises et les changements apportés sur les composantes de l'environnement collaboratif au cours de la période 2015-2019, en dégageant les grandes axes d'évolution auprès de l'ensemble de la communauté, i.e. utilisateurs, collaborateurs et développeurs, dans le but de :
Les choix et orientations suivies
[paragraphe "1/4 heure warholien" demandé]
...
To-do list:
- illustrations!
- paragraphe dans état des lieux sur la gestion documentaire
L'infrastructure au moment de la rédaction initiale de ce document est constituée des éléments suivants :
Défauts de constructioninitiaux
Reprenant le code numérique OPA (Ocean PArallélisé
) né au sein du laboratoire LOCEAN (ex-LODYC) qui fait parti de la fédération IPSL sur le site du campus Pierre et Marie Curie - Sorbonne Université (ex-Jussieu Paris 6), le projet NEMO a de fait hérité des outils collaboratifs déjà mis en place et utilisé localement (forge logicielle et listes de diffusion). Dans la foulée le site web www.nemo-ocean.eu a été inauguré avec un hébergement du serveur sur site.
Cet bref historique de la genèse du projet permet déjà de pointer l'impossibilité d'une réflexion d'ensemble préalable sur les systèmes, leurs articulations entre les services offerts et les type d'audience visés (grand public > utilisateurs > contributeurs > développeurs > administrateurs).
Pour un projet de développement logiciel collaboratif par équipes distantes, un problème critique apparaissait tout de suite: toutes les ressources en ligne du projet étaient concentrées en une infrastructure informatique non redondée sur un site unique.
La communication et les opérations de maintenance sont sans doute améliorées par le fait d'être physiquement à côté des installations et d'avoir des techniciens de support analogue à des collègues; mais cela ne contrebalance pas l'inéluctabilité d'une mise hors-ligne complète et de manière intempestive du projet, même sur une courte période.
Dans ce cas de figure, le problème n'était pas tant pour les développeurs, qui pouvaient occuper leur temps sur le projet en mode hors ligne, que les utilisateurs qui se retrouvaient dépourvus de ressources et sans information car les administrateurs n'avaient plus les moyens de communiquer directement auprès d'eux.
Une autre conséquence de cette absence d'organisation préliminaire a été un désordre certain dans les contenus proposés notamment au travers des 2 wikis existants (site web et forge): les différents groupes de la communauté n'avaient pas de point d'entrée en ligne clair et unique qui regrouperaient toute l'information disponible leur étant dévolue.
Non seulement les visiteurs peinaient à trouver l'information en cherchant un peu à l'aveugle, mais cet éparpillement des pages web demandait également plus de travail aux éditeurs pour maintenir un même contenu à jour dans différents emplacements.
Avant le passage en revue chacune composante, une fonctionnalité implémentée au lancement de l'environnement est aussi devenu problématique à l'usage: maintenir une authentification commune entre 2 systèmes indépendants. L'avantage d'une telle fonctionnalité est évidente: l'utilisateur rentre un seul jeu identifiant-mot de passe pour se connecter ou s'authentifier sur les différents services et l'administrateur lui fait croire en un système unique parfaitement intégré. Mais l'illusion requiert d'assurer une parfaite symétrie (site web <=> forge) ce qui n'était pas le cas, d'où des requêtes régulières vers les administrateurs venant de développeurs déconcertés après une réinitialisation de mot de passe coté site web attendue comme propagée sur la forge.
En grande partie, la version publique du site web donnait ce que l'on était en droit d'attendre de la vitrine d'un projet en décrivant son origine et ses caractéristiques principales ainsi qu'en mettant à disposition son accord fondateur. Les 2 reproches à adresser sont d'un autre registre: l'un organisationnel et l'autre technique.
Faire du site web le portail principal de sa communauté s'entend pour la plupart des activités mais pas dans le développement logiciel, où tout tourne autour du code source, son développement et son support. La plateforme web de la forge ne pouvait peut-être pas offrir toutes les fonctionnalités additionnels disponible sur le site web (gestion de comptes et forums de discussion), mais elle proposait une solution de base adéquate et avait l'avantage d'une intégration parfaite avec le dépôt des sources. Tout cela aurait du en faire le centre quasi exclusif des opérations de la communauté.
Le vrai point noir du site web version 2008 a été le choix peu avisé de la solution Ez Publish pour la gestion de contenu: vouée aux sites e-commerce, elle s'est avérée d'une prise en main difficile pour les éditeurs de page et les administrateurs; sa maintenance externalisée et déclenchée au coup par coup a été d'un coût prohibitif (~30 k€ en cumulé), qui n'a même pas empêché le piratage du site en 2015 heureusement sans conséquence.
Parti d'un système de gestion de versions sous CVS avec ViewVC comme interface web, le code source a été migré en 2007 sur une nouvelle architecture hébergée à l'IPSL
Sur le temps long ce choix s'est avéré tout à fait judicieux, cette organisation duale de développement SVN+Trac est d'ailleurs devenue très répandue dans les forges logicielles. Cela a permis de disposer d'un support continu sur ces programmes et d'un catalogue d'extensions Trac abondant pour la mise en place de nouvelles fonctionnalités.
Cependant un choix de configuration réseau fait par le service informatique IPSL couplé à cette fonctionnalité de synchronisation de compte depuis le site web évoqué plus haut ont fait que cette installation n'était pas tout à fait optimale pour le projet NEMO.
En particulier pour un développeur, il n'était pas aisé pour lui de comprendre qu'il avait en fait 2 compte distincts sur la forge:
Initialement les 2 comptes partageaient les mêmes identifiants et ainsi semblaient ne faire qu'un, mais cela n'était pas prévu pour durer. L'incompréhension était alors de mise au changement d'un mot de passe, sans parler des copies de travail configurées soit en mode utilisateur soit en mode développeur.
La management des développeurs manquait également de souplesse puisque il y avait seulement 2 administrateurs situés uniquement sur Paris qui pouvaient promouvoir un nouveau développeur dans l'équipe.
Par ailleurs, on pouvait faire plusieurs observations sur l'organisation et la gestion du dépôt ainsi que la structure de code NEMO (situation du dépôt avant modernisation)
Un jugement péremptoire qui résumerait à gros traits les constatations précédentes est un dépôt anarchique laissé à l'abandon et une structure de code obsolète.
Le projet NEMO avait crée 3 listes de diffusion pour le partage d'informations :
commits) et les notifications du gestionnaire de tickets (création/mise à jour ou ajout d'un commentaire)
NEMO System Team) mais servant parfois également de liste de support.
De manière générale le nombre, les sujets et les destinataires des listes de diffusion s'agencent bien avec les 3 grands groupes du projets (utilisateurs > contributeurs > développeurs) mais on rencontre plusieurs inconvénients
En me basant sur l'état des lieux décrit dans la partie précédente et après consultation auprès des publics concernés (instituts du consortium, développeurs et contributeurs du code, hébergeurs), j'ai construit et mené dans le temps long et en plusieurs étapes un plan d'évolution général de l'environnement numérique du projet. Affectant toutes ses composantes, il se proposait de corriger les défauts évoqués, de moderniser les outils déjà à l'œuvre et de mettre en œuvre de nouveaux services pour la communauté tout en ayant le moins d'impact possible de par son implémentation.
En ces temps où les ressources sont contraintes et l'expertise précieuse, j'ai défini 4 orientations majeurs à appliquer pour s'approcher d'un environnement stable à un coût modique avec des outils intégrés et des tâches d'édition/administration aisés.
De mon expérience au sein du projet NEMO, j'ai distingué 4 groupes principaux dans la communauté pouvant avoir des besoins spécifiques par composante :
Ensuite par composante puis par application, la stratégie était de revoir les publics cibles (certains groupes pouvant être temporairement fusionnés) et de mettre en pratique dans la mesure du possible les orientations définies afin de trouver un compromis entre les 2 à 3 groupes non fusionnels et les possibilités d'adaptation de l'application.
Tout cela dans le but de limiter la personnalisation superflue et les besoins de maintenance sur le court terme, afin de préserver le potentiel évolutif et la capacité de migration à moyen-long terme.
L'une des principales finalités du plan de rénovation était que la forge logicielle devienne le portail en ligne central du projet ce qui a engendré quelques décisions organisationnelles fondamentales
La démarche pour sa reconstruction expurgé de son contenu sui generis vers la forge. On s'affranchit alors de mises à jour fréquentes ainsi que d'une gestion de comptes compliquée et les seules apports attendus dans la vie du site seront :
Special IssueNEMO chez GMD
Un compte éditeur a été créé pour tous les NEMO Officers ainsi chaque institut a la possibilité de publier ou d'éditer les pages, le déclenchement d'une révision complète des pages se faisant au minimum à chaque nouvelle version officielle du code.
Le plan du site était comme suit à sa mise en ligne en 2016 et a depuis été revu à la marge (menus remaniés avec une liste des page inchangée).
Côté technique, l'attention a été particulièrement porté sur la sélection du système de gestion de contenu tant décrié dans la version antérieure du site. Le choix s'est porté sur WordPress, solution plébiscitée pour les blogs en ligne et correspondant à l'orientation voulue pour le contenu du site et la convivialité de l'interface. Le service informatique de Mercator Océan s'est proposé de l'héberger gracieusement nous assurant un support sur mesure.
Pour la configuration du site il a été procédé à l'installation de greffons WP, on peut citer comme travaux principaux
Afin de
• NEMO officers granted as Forge administrators a widen access (1 administrator per institute)
✔ Regroup all ST activities (calendar, documents, wikis, ...) in one collaborative development platform on IPSL Forge
✔ No more worry on password issues with a tight division between user/developer accounts and garbage messages on '[Systeam]', with new Trac notification system and mailing list configuration
Generally, IPSL Forge is suitable for a source code with a limited number and permanent developers/users, so appears not too well configured for us.
Before: Register on the previous website to access to IPSL Forge for downloading the code and reporting bugs/issues Find the documentation for compiling and running the code and a discussion forum in the User website area Ask for support on '[Nemo]' & '[Nemo_st]' mailing lists and receive the news for the project via '[Nemo]' mailing list
After: New Users Forge will centralize all tools (repository, wiki, forum, ticket, ...) with
◦ a reworked documentation
◦ an archiving and searching feature
◦ an integrated mailing lists '[News]' & '[Tickets]' for a top-down communication
● Developer
Before: Find the informations and contents for the System Team partly on the previous website and partly on IPSL Forge Encounter connection problems by confusing his user/developer account Receive Trac notifications for commits & tickets, and external support requests on '[Nemo_st]' mailing list for internal communications
Tags Tag cloud Forum Calendar
The main trouble with these lists is to maintain their consistence with members of related groups (effective accounts on website for '[Nemo]' & current Forge developers for '[Nemo_st]').
On the subject of the mailing lists, it is an opportunity to redefine their object and change their configuration:
➔ '[Nemo]' mailing list will be replace by a strict newsletter with custom address 'news@nemo-ocean.eu', called '[News]' hereafter (open access but no posting allowed expect from NEMO System Team).
➔ '[nemo_ticket]' mailing list will be replace by a strict newsletter with custom address 'tickets@nemo-ocean.eu', called '[Tickets]' hereafter (open access but no posting allowed at all, just a notification list)
➔ '[Nemo_st]' mailing list will be replace by a confidential list with hidden address 'systeam@nemo-ocean.eu', called '[Systeam]' hereafter (subscription controlled, no external posting).
➔ the mailing lists will be created in the applicative services provided by RENATER (French national network for education & research )
Before: Does several repetitive tasks of moderation on the previous mailing lists
After: No more moderation activities with new configuration of the mailing lists
No hurry to carry out any change as the software does the trick, the availability is not primary and CNRS has full support for now and the future, except a restriction for administrators (login required on LOCEAN network)
...
Ces dernière années la tendance dans le développement logiciel est de mettre la documentation du code à disposition directement dans les sources sous la forme de plusieurs fichiers texte écrit avec un langage de balisage léger (type Markdown ou ReStructuredText) qui est lisible en l'état dans un éditeur de texte tout en pouvant l'exporter dans un format web (HTML) ou imprimable (PDF)
Par ce moyen, on s'assure que la documentation est toujours consultable dans le temps long à partir d'une copie des sources même si la version du code n'est plus répertoriée en ligne et le langage de balisage obsolète ne permet plus l'export.
Une communauté NEMO a été crée sur la plateforme d'archives ouvertes Zenodo qui offre un service d'archivage en ligne par versionnement dans le but de
...
...
...
...
Realistic roadmap
For that, I propose to do the migration in 2 steps: first step in short term to quickly erase some flaws (registration process & repository availability for users, creation of developer account, '[Nemo]' mailing list update), and second step in medium-term to allow time for discussion on the NEMO ST to make the right choice and to smooth transition to a new website or a new full CDE until the end of life of the web server (31/03/2017).
First evolution phase
The new configuration of the existing tools in NEMO CDE might look like:
Public → Website (new or previous one) reduced to its public area, ultimately no further editing
Users → New public Forge with registration and hosted externally for availability purpose
Developers → Existing Forge hosted in IPSL with NEMO officers granted as administrators
(NEMO project on Forge, NEMO Trac & '[Nemo_st]' mailing list)
ST → Existing Forge hosted in IPSL who becomes the only project management portal
For the particular situation of the members of Developers Committee, the better solution just now is to let them with their restricted area on the website and postpone the move when we will have a clear idea for their future localization in the CDE (Forge IPSL, users Forge or new website).
• 2-steps roadmap throughout the year 2016 to prepare a prospective migration • Removing existing defects and decreasing future workload • Postponing an aware decision before the EOL of the web server
1st phase main operations
• Website reduced to its public area
• New public repository for users
• NEMO officers granted as Forge administrators
• Trac becomes the only management portal
• Appraisal after few months of activity to conclude on moving or not to the 2nd phase
• If required, implementing new website
• If not satisfied with this new architecture, considering a whole migration
Second evolution phase
A review will be made after this first phase (≈ 3 months) so that the ST will decide whether if it is better to enter a second evolution phase by the end of the web server (31/03/2017), namely the next CMS of its new website and a possible new full CDE.
Public: Previous website: no apparent change, public area must remain the same New website: of course a new homepage and site map but with same content Redundancy will be still an issue but with much less impacting Removing private data accessible in case of hacking Little by little emptying the amount of data to transfer later
Users: Downloading limited to the trunk, stable releases & updates (NERC/UKMO branches ?) Registration process transferred to new Forge with updated documentation and few integrated features like wiki, integrated mailing list & forum/issue tracking Renewing registration if no ability to transfer all user accounts Keeping '[nemo_ticket]' mailing list on IPSL Forge for those concerned
ST: Using gradually Trac instead of the website for all management tasks & activities and shared actions (agenda, collaborative editing, document design, work plan, ...) Archiving existing content in website for information (just reading rights) Creating How-tos content for new Forge from current web pages: user guides (10), configurations (12), FAQ (1) & utilities (≈10), part of this was related to the release of NEMO 3.6 Implementing & ensuring the synchronization between 2 Forge (developers → users) Ending slowly '[Nemo]' mailing list (erasing duplicates with mailing list of Forge users) Trac administration: probably defining news roles and installing few new plugins