OUI et NON
(bien que je ne sois pas normand !)
Il y a plusieurs paramètres à prendre en compte à mon avis.
Pour moi, il y aurait bien un problème de mutualisation AVANT un problème de finalisation.
On va partir du micro pour arriver au macro en listant les process (du moins, ce que je comprends depuis mes observations).
1. Besoin local
Tout commence dans un service où une instance Moodle doit répondre à un besoin particulier.
Faute de trouver un plugin existant, une personne ayant connaissance du code développe un plugin ou quelque chose qui permet de répondre à son besoin, suivant son contexte.
C'est la naissance d'un plugin, d'un webservice, d'un patch...
2. Besoin partagé
De bouche à oreille, via des groupes de travail, des messages dans la communauté, des
courriels ou appels téléphonique, ou via des MoodleMoot, quelqu'un répond à une demande en disant "j'ai fait ça, tiens", ou "regarde ce que j'ai fait, et vois si ça peut t'aider".
Ce partage, cet échange de code (restons neutre) se fait en envoyant le fichier ou le lien vers le zip ou dépôt du 1er contributeur.
Pour moi, cette 1ère étape serait primordiale pour savoir qui (a) fait quoi qui pourrait éviter à une autre personne de réinventer la roue.
3. Plugin documenté
Lorsque ces échanges sont en place, il est souvent vu que les 2 personnes collaborent à améliorer leur code pour qu'il soit plus clair à comprendre, plus facile à modifier suivant le contexte de réutilisation.
Pour moi, cette 2ème étape serait indispensable pour améliorer la description des contextes de création/développement/modification du plugin à toute fin d'amélioration par d'autres.
Cela pourrait également résoudre en partie la problématique du développeur qui quitte le service et qui laisse le "bébé" sur place...
4. Plugin aux normes
Le besoin grandissant, la demande se faisant plus forte au sein des communautés de pratiques, et pour pérenniser le développement, il faut en effet normaliser le code pour proposer ce plugin dans la base officielle.
Ici, il faut que les personnes respectent les normes attendues par Moodle HQ pour que tout se passe bien.
Pour moi, cette 3ème étape est importante pour donner une visibilité plutôt Mondiale au développement en passant par cette phase de "plugin en attente d'approbation".
5. Plugin disponible dans la base officielle
Ici, nous touchons au but. Une fois le plugin approuvé, il est listé dans la base officielle des plugins.
Une nouvelle vie lui appartient désormais entre les multiples usages, téléchargements, retours, demandes...
6. Plugin intégrant le core
Ici, nous touchons au sein Graal. Il faut avoir en tête qu'il y a plusieurs chemins :
- l'impasse --> le plugin restera plugin disponible depuis la base
- le contributif --> en passant par la Moodle Users Association, en passant par les votes depuis le tracker, il est possible qu'un plugin tiers (ou patch...) devienne un plugin core
- le coup de coeur --> au vue de son indispensable intérêt pour la communauté mondiale, il est rapidement intégré
En résumé :
Là où je me pencherai avant tout, c'est ce passage entre le local et le partagé.
C'est ici qu'il y a, pour moi, déjà un manque de visibilité.
Car un besoin local, peut avoir été comblé ailleurs. Mais si on ne le sait pas...
Si on pouvait déjà centraliser, non pas les codes qui impliquerait un github commun à tous, mais au moins un lien vers le code et un descriptif documenté (soit dans le code, soit par un document associé), on pourrait voir/savoir ce qui est disponible et pour quels usages.
Ce serait comme un sas intermédiaire, avant la possible soumissions pour approbation.
Évidemment, tous les développements locaux n'ont pas la vocation à devenir plugins officiels.
Il y a tellement de spécificités souvent dans les besoins que seul un établissement de même structure, avec un même annuaire, avec des mêmes procédures de webservices pourraient vraiment en avoir besoin.
Mais ça entrerait déjà dans un process de partage et mutualisation à mon sens.
Et, pour finir, ma vue du process de "celui qui a besoin" :
- j'ai un besoin spécifique
- je regarde dans la base des plugins s'il existe quelque chose
- SINON je regarde dans les plugins en attente d'approbation
- SINON je regarde dans la base des plugins interétablissements mutualisés
- SINON j'appelle un ami
Je me trompe peut-être de vision (je ne suis pas développeur, mais je fais développer
)
Mais je pense qu'il y a des choses à faire pour remonter les informations.
