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:dolibarr-association-bounces+charles.fr=benke...@nongnu.org] De la part de The mailing-list for Dolibarr foundation members Envoyé : lundi 17 octobre 2016 18:39 À : Posts about Dolibarr ERP & CRM development and coding <dolibarr-dev@nongnu.org>; dolibarr-associat...@nongnu.org Objet : Re: [Dolibarr-association] [Dolibarr-dev] Dolibarr 4.0.1 Hello I agree with Charlie and not only for creativity reason. I think this point as to be debated to the next devcamp in Valencia. Regards Philippe Scoffoni Le 15/10/2016 à 14:51, Charles Benke a écrit : Hello, 10 years is a good year to change his use, be more adult 5.0 is a REAL major version IF they include as stable multicurancy and accountancy In other case they will be another disturbish version who decrease the number of sell in the Dolistore. 6 month between 2 major version freeze the creativity of developpers, We have waiting 3 years to have the accountancy stable in Dolibarr and without the crownfunding of darkjeff, I suppose that we have to wait 3 years more this major feature Once again I ask to change the scheduling of the major release to 1 by year and I propose to plan a vote for change the roadmap ASAP Bien cordialement, Charlie Benke De : Dolibarr-association [mailto:dolibarr-association-bounces+charles.fr=benke...@nongnu.org] De la part de The mailing-list for Dolibarr foundation members Envoyé : samedi 15 octobre 2016 11:47 À : ML Dolibarr dev <mailto:dolibarr-dev@nongnu.org> <dolibarr-dev@nongnu.org>; ML Dolibarr Foundation <mailto:dolibarr-associat...@nongnu.org> <dolibarr-associat...@nongnu.org> Objet : [Dolibarr-association] Dolibarr 4.0.1 Hi. Just a note to let you know that dolibarr 4.0.1 has been released. 4.0.1 is just a very minor bugfix version compared to 4.0 to fix issues discovered just after release of the major version 4.0 The current development branch should also be frozen soon to start the 5.0 beta period. Goal is to release 5.0 in january as stated in the roadmap we follow from 10 years now (1 major version in january and 1 in july) Version can be downloaded from official portal https://www.dolibarr.org _______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org <mailto:Dolibarr-dev@nongnu.org> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
