Gestion du projet Pluxml
Plop,
J'ai lu ici et là l'enthousiasme généré par Pluxml et c'est encourageant pour Skyline. C'est encourageant et mérité car l'outil promet de belles choses pour peu que l'on ne mette pas la charrue avant les boeufs ..
Gestion du développement
Skyline a développé seul cet outil. Je pense qu'il est aussi dans son idée de continuer seul à le développer ce que je pense être le mieux. Tout le monde ne maitrise pas forcément le xml comme lui.
On considère donc que c'est lui seul qui gère le développement officiel de pluxml. C'est donc lui aussi qui numérote les différentes versions et qui sait lorsqu'une version est proposable en téléchargement ou pas.
Nous en sommes à la 0.2.0 c'est à dire loin d'une 1.0.0, chiffre qui symbolise en général une toute première version stable d'un outil développé de manière collective (suggestions + codage). 1/5eme du chemin a été parcouru et nous disposons déjà d'un outil efficace. Laissons donc le temps au temps et testons sous toutes les coutures cette version 0.2.0 pour commencer.
Gestion des bugs
Le deboggage est important pour un script grand public. J'allais dire que les bogues étaient inévitables mais je rectifie : ils sont souhaitables. Nous sommes tous sous des plateformes différentes avec des systèmes d'exploitations différents. Cela permet de tester pluxml dans différents environnements et de rapporter des bogues de manière significative.
Une liste de deboggage par système et version de pluxml serait presque à mettre en place. Mais pour l'instant, une liste commune permet de rassembler les bogues. Il vous faut juste ne pas oublier de bien spécifier si vous travaillez en local, sous quel système, quelle version de ce système, etc... Enfin bref, n'oubliez aucun des paramètres qui pourraient aider skyline dans son travail de correction.
Gestion des addons
Vous en proposez beaucoup et c'est bien mais je pense que hiérarchiser ces propositions d'améliorations est souhaitable pour tous. Ainsi, la gestion d'images (sous quelque forme que ce soit, en core ou en plugin) est peut etre plus important comme amélioration que la gestion des autres médias (vidéos par exemple).
Chaque idée d'amélioration peut etre proposée et discutée. C'est là toute la richesse d'une communauté comme celle de pluxml. Chacun peut apporter sa pierre tout en sachant qu'elle ne sera pas forcément retenue au final.
Gestion des idées
Les idées fusent. Mais à vrai dire, lorsque ça fuse de partout c'est le bin's. Imaginez skyline : il doit jongler entre les bugs, le développement et les idées qui tombent de partout. Le mieux est de lancer un post par idée, aussi saugrenue soit-elle. Chacun pourra y dire son avis, sa faisabilité, son interet, etc...
Et l'avenir ?
Le but de tout cela est d'arriver à une version stable et si possible au moins bilingue pour que l'outil puisse être exporté facilement vers d'autres pays qui ne parlent pas forcément le français.
Conclusion
Il n'y a pas le feu ! pluxml est tout jeune et marche à peine sur ses 4 jambes. Laissons lui le temps de s'épanouir gentiment, de prendre des forces et d'avancer.
J'ai lu ici et là l'enthousiasme généré par Pluxml et c'est encourageant pour Skyline. C'est encourageant et mérité car l'outil promet de belles choses pour peu que l'on ne mette pas la charrue avant les boeufs ..
Gestion du développement
Skyline a développé seul cet outil. Je pense qu'il est aussi dans son idée de continuer seul à le développer ce que je pense être le mieux. Tout le monde ne maitrise pas forcément le xml comme lui.
On considère donc que c'est lui seul qui gère le développement officiel de pluxml. C'est donc lui aussi qui numérote les différentes versions et qui sait lorsqu'une version est proposable en téléchargement ou pas.
Nous en sommes à la 0.2.0 c'est à dire loin d'une 1.0.0, chiffre qui symbolise en général une toute première version stable d'un outil développé de manière collective (suggestions + codage). 1/5eme du chemin a été parcouru et nous disposons déjà d'un outil efficace. Laissons donc le temps au temps et testons sous toutes les coutures cette version 0.2.0 pour commencer.
Gestion des bugs
Le deboggage est important pour un script grand public. J'allais dire que les bogues étaient inévitables mais je rectifie : ils sont souhaitables. Nous sommes tous sous des plateformes différentes avec des systèmes d'exploitations différents. Cela permet de tester pluxml dans différents environnements et de rapporter des bogues de manière significative.
Une liste de deboggage par système et version de pluxml serait presque à mettre en place. Mais pour l'instant, une liste commune permet de rassembler les bogues. Il vous faut juste ne pas oublier de bien spécifier si vous travaillez en local, sous quel système, quelle version de ce système, etc... Enfin bref, n'oubliez aucun des paramètres qui pourraient aider skyline dans son travail de correction.
Gestion des addons
Vous en proposez beaucoup et c'est bien mais je pense que hiérarchiser ces propositions d'améliorations est souhaitable pour tous. Ainsi, la gestion d'images (sous quelque forme que ce soit, en core ou en plugin) est peut etre plus important comme amélioration que la gestion des autres médias (vidéos par exemple).
Chaque idée d'amélioration peut etre proposée et discutée. C'est là toute la richesse d'une communauté comme celle de pluxml. Chacun peut apporter sa pierre tout en sachant qu'elle ne sera pas forcément retenue au final.
Gestion des idées
Les idées fusent. Mais à vrai dire, lorsque ça fuse de partout c'est le bin's. Imaginez skyline : il doit jongler entre les bugs, le développement et les idées qui tombent de partout. Le mieux est de lancer un post par idée, aussi saugrenue soit-elle. Chacun pourra y dire son avis, sa faisabilité, son interet, etc...
Et l'avenir ?
Le but de tout cela est d'arriver à une version stable et si possible au moins bilingue pour que l'outil puisse être exporté facilement vers d'autres pays qui ne parlent pas forcément le français.
Conclusion
Il n'y a pas le feu ! pluxml est tout jeune et marche à peine sur ses 4 jambes. Laissons lui le temps de s'épanouir gentiment, de prendre des forces et d'avancer.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Il ne faut pas se presser, mais cependant, ca démarre très bien !
faisant partie d'une team qui developpe un CMS, je pense qu'il faut que des personnes s'enflammes pour faire vivre un projet, c'est l'essence meme de la motivation et d'une reconnaissance indirect envers son auteur.
De plus, des personnes demanderons avec cela de pouvoir participer et s'inverstir dans differents rôle s'afferent autour de ce projet (forum, design, communication, documentation, developpement, etc....).
je ne dirais pas ce n'est qu'une 0.3, mais plutôt c'est deja une 0.3 (la difference reside dans le fait que ce projet n'as pas beaucoup de temps mort).
Bon courage pour la suite, hervé