Valery Fremaux

Bonjour,

Il n'y a pas a proprement parler de "validation" par la communauté. Par contre, vous pouvez vouloir déposer votre code dans les contributions de Moodle et avoir pour ce faire accès au CVS. POur cela vous devez en effet demander un login à la communauté, et justifier de pourquoi vous voulez obtenir cet accès. Il vous sera donné un accès en écriture à votre sous-branche de plugin.

Vous pouvez contacter pour cela Anthony Borrows qui coordonne les plugins tiers (en anglais), ou envoyer une demande plus générale à support@moodle.org

Précisez bien pour quelle version. Pour faire écho à mon ami Daniel, il serait logique que les nouveaux développements visent Moodle 2.0, Mais la réalité est aujorud'hui que 95% des sites tournent encore sous Moodle 1.9 et que l'usage de Moodle 2 reste aujourd'hui expérimental par une partie avancée de la communauté : si vous cherchez de l'audience ou une surface de test ou de validation il est donc logique que vous commenciez par cette version , mais il faudrait intégrer dans votre travail la produciton de la version 2.0 dès le début. (Ce sont, au niveau d'un module qu'un ensemble d'appels de librairies à retravailler)   

Possible que ce soit "Customer Relationship Management"

mais je ne suis pas tout à fait sûr que cela corresponde tout à fait à la définition ici....

Il vaudriat probablement mieux gérer les aspects administratif et événement de gestion dans un logiciel plus orienté CRM (vtiger, sugarcrm ou autre CRM du marché), et laisser à Moodle uniquement la partie "action pédagogique".

Avec un CRM en php, il est pas exclu de pouvoir monter une petite intégration sur l'authentification ou la diffusion des comptes à Moodle.  

V

Non, la version "officielle" du flexi page n'est pas critique du tout. La nouvelle non plus d'ailleurs (elle ne fournit pas les améliorations qu'elle porte, c'est tout).

"Mais cela peut donner des pistes pour les équipes de dev officielles pour intégrer les amélioration qui font défaut à l'environnement actuel"

C'est l'un des fond du problèmes, la grogne profonde des Moodle Partners envers la version Moodle 2.0 est que la plupart des critiques et propositions (peu on été suivies, certaines ont été résolues très différemment, et d'autres restent dans le même état qu'avant...) ont peyu été prises en compte.

Les améliorations fortes développées depuis des années par la communauté technique concernant l'intégrabilité, l'administration facilitée, le "monitoring" des apprentissages sont passés lettre morte....

Je respecte tout à fait ton recul à gérer des améliorations structurelles (mais non standard) de Moodle. C'est en effet impliquant (un peu, car les points de modification ne dépassent pas, dans une version très modifiée, la 40 aine de points dans plus de 12.000.000 de lignes de code !!!!!!)

Cheers.

Super exercice de langue de bois dogmatique, Daniel.

Il y a dans la communauté des niveaux de compétences très divers, depuis des utilsiateurs sans aucun bagage tchnique jusqu'à des développeurs et architectes chevronnés.

Le procés en "hérésie" que tu fais est dign des plus beaux discours inquisitoriaux de l'histoire.

Les développements innovants n'ont rien d'asservissants, lorsque'ils sont gérés dans certains cadres. Ce n'es tpas blanc ou noir, patch ou pas patch, orthodoxie ou hétérodoxie.

Il y a des degrés d'adaptation plus ou moins problématiques. Pairformance est l'un des cas pires en effet, car c'est le cahier des charges du commanditaire qui a dominé. C'est une "commande" fonctionnelle à l'aquelle il n'était pas vraiment possible d'opposer, un "ah oui mais non, vous voyez, on peut pas faire....", bien trop courant sur le marché des prestations de service très chères (et peu compétentes). 

Pour l'amateur qui gère lui-même son Moodle, ou pour les équipes techniques d'institutions submergées d'autres problèmes, oui, la modification en profondeur pose problème. C'est connu et bien documenté.

Le tout est de savoir si la plate-forme doit servir ses usagers, et permettre d'obtenir des usages riches, ou si elle doit servir la tranquilité de ses administrateurs. Il existe des techniques efficaces de gestion des modifications qui portent le coût d'une mise à jour "avec patchs" à moins d'une demi journée.

Cependant, on ne le dira jamais assez : c'est aussi aux développeurs qu'il faut passer en effet le discours de proposer des solutions qui s'inscrivent LE PLUS possible dans les cadres de l'exensibilité de la plate-forme, en utilisant toutes les entrées de plugin qui permettent d'éviter certaines extrémités.

Non Claude, la version déployée dans Scolastance sur Strasbourg suit les traces d'une version hyperstable (1.9) et qui permet d'envisager un déploiement et une maintenance sur à terme plus de 150 instances de Moodle.

Les demandes de mutualisation inter-établissement, et la circulation des volumes de cours entre plates-formes se sont aujourdéhui heurtés, dans Moodle 2.0 à plusieurs points architecturaux qui posent problème aux intégrateurs, même s'ils ont des arguments bénéfiques par ailleurs.

Moodle 2.0 reste encote pour les professionnels de l'intégration, une piste encore expérimentale qui demandera beaucoup d'efforts pour intégrer tous les acquis de la branche 1.9.