|
| From: | Charles Benke |
| Subject: | Re: [Dolibarr-dev] [Dolibarr-association] Dolibarr 4.0.1 |
| Date: | Tue, 8 Nov 2016 15:20:10 +0100 |
|
This will be my last post on the subject because I'm tired of wasting my time and to also lose the other, a French version is available at the bottom of this message because my English is too rots I would like to address two notions someone does not understand that is the financial aspect and the marketing aspect of a project management, Usually managed by the Product Manager On the financial side must understand that time and necessarily the money that is used by developers, integrators and users to update their environment each mounted major versions are not invested in the development of new functionality and search reliability - How an integrator for example it can monetize time spent know a version of dolibarr if after 6 months he must start from zero? - This is why the major functionality we all expect (the advanced accounting, multi-currency, ...) are still not present in the stable release in the core: the community spends time updating its versions In short, the major technical version output timing is counterproductive and flange willingness to invest in dolibarr without dolibarr investment gold will not continue to grow ... On the marketing side, change the numbering rules without giving any explanation to the community (which can not be reduced just to the mailing list of developers ...) is a bad method, misleading limit, because it is believed that there is novelty in dolibarr whereas there is no functionally. At one point we must understand that the project manager to work is not a technique, it is also financial and marketing gold Dolibarr on this aspect is really lagging. Not taking into account two parameters in the roadmap, version numbering is counterproductive. I therefore propose that the next devcamp December to be debated Valencia two points: - The Roadmap major technical versions of Dolibarr that must be passed to a version a year only and ideally by the end of June / early July to enable the integrator / advanced users willing to go up anomalies during the summer and offer the a new version of the more stable and reliable for September, the most active period for implementing an ERP. - A numbering where the first number is the major functional versions of Dolibarr, the second major issue technical version and the latest patch releases Hoping that some end up taking consience it's not just developers who use dolibarr ... ------ Ce sera mon dernier message sur le sujet car j'en ai assez de perdre mon temps et de faire perdre aussi celui des autres, une version en français est disponible en bas de ce message car mon anglais est trop pourrit J'aimerai aborder deux notions quelqu'un ne semble pas comprendre à savoir l'aspect financier et l'aspect marketing d'une gestion de projet, généralement géré par un chef de produit. Sur l'aspect financier il faut comprendre que le temps et forcément l'argent qui est utilisé par les développeurs, intégrateurs et utilisateurs pour mettre à jour leur environnement à chaque monté de versions majeurs n'est pas investie dans le développement de nouvelle fonctionnalité et la recherche de fiabilité - comment un intégrateur par exemple peut-il rentabiliser le temps passé à connaitre une version de dolibarr si au bout de 6 mois il doit tout reprendre de zéro? - c'est la raison pour laquelle les fonctionnalité majeures que nous attendons tous (la comptabilité avancé, le multidevise, ...) ne sont toujours pas présente en version stable dans le core : la communauté passe du temps à mettre à jour ses versions Bref, ce timing de sortie de version technique majeur est contreproductif et bride la volonté d'investir dans dolibarr, or sans investissement dolibarr ne pourra continuer de se développer... Sur l'aspect marketing, changer les règles ne numérotation sans donner la moindre explication à la communauté (qui ne se résume pas juste à la mailing list des développeurs...) est une mauvaise méthode, limite mensongère, car elle fait croire qu'il y a de la nouveauté dans dolibarr alors qu'il n'y en a pas fonctionnellement. A un moment il faut comprendre que le travail de chef de projet n'est pas que technique, il est aussi financier et marketing, or sur cette aspect Dolibarr est vraiment à la traine. Ne pas prendre en compte ses deux paramètres dans le roadmap, la numérotation des versions est contreproductive. C'est pourquoi je propose que lors du prochain devcamp de décembre à Valence soit débattue deux points : - Le Roadmap des versions techniques majeurs de Dolibarr qui doit être passée à une version par an seulement et idéalement pour la fin juin/début juillet afin de permettre au intégrateur/utilisateurs avancées de bonne volonté de remonter les anomalies durant la période estivale et offrir au novice une version des plus stable et fiable pour la rentrée, période la plus active pour mettre en place un ERP. - Une numérotation où le premier numéro correspond aux versions majeures fonctionnelles de dolibarr, le deuxième numéro aux version majeures techniques et le dernier aux versions de correctifs En espérant que certains finissent par prendre consience qu'il n'y a pas que des développeurs qui utilisent dolibarr ... Bien cordialement, Charlie Benke De : Dolibarr-association [mailto:address@hidden De la part de The mailing-list for Dolibarr foundation members Hello Le 15/10/2016 à 14:51, Charles Benke a écrit :
|
| [Prev in Thread] | Current Thread | [Next in Thread] |