Hi Fabien, I hope you don't find it to rude, but here are a few early answers to your questions. I'm really hope to do a constructive feedback.
2.1. What do you think about Launchpad ? Customer/ End users will hardly like it. Developers might think it's OK, while it's a big mess. But I'm not telling there are better solutions at this scale. Ultimately I think there should be a place to download any module (be it from extra addons) somewhat tagged with it's revision number so non tech users could easily test a module from there, may be interface the module manager and Launchpad somewhat. 2.2. Is it clear and easy on how to contribute ? It's not "easy". People don't know Bazaar. Launchpad is a total mess (again I'm not telling better place exist). It's crazy, it's easier to find a closed bug using Google than the Bazaar search engine... 2.5. Any idea on how to increase the community of Open ERP ? Be quicker at integrating patches. ALWAYS cross reference patches and commit. At each commit, mention the name of the contributor to reward community. Be more clear on what is good out of the box and what isn't so that more people stick with OpenERP without being disappointed later on because it's not their fit eventually. Never commit again using "modifs/improvement" please. People can't follow that on trunk. Explain why half of commits message are "merge" (I know it but noobs will think it's just like 'modifs'). 2.7. The planets It's not clear at all what is the process to get included. Myself wrote some English posts that were not included, I'm not alone. 3.1. Working with Launchpad / Bazaar. Is it clear ? Do you use LP or others ? We like Bazaar but it's nothing easy for newcomers. 3.2. What the suggested development environment ? Eclipse+ Pydev (people wanting it will know how to do it). But IMHO the unit test framework is not enough. OpenERP should have real test suites (like Rails or JRuby one if you like, I mean thousands of real unit tests, the current system it to hard to replay independent tests systematically). A bug should ideally generate a unit test to ensure it won't occur ever again. 5.1. What should be improved ? technical guide, user doc ? Docstring in the core code. Please don't use anymore meaningless variable like 'todo' or 'a' or whatever meaning less when you could use a meaningful variable name. 5.2. Someone proposed to keep the old Wiki ? Why ? In any case, lot's of people would be able to contribute on a wiki while they can't afford learning Bazaar. So you need to lower the contribution entry barrier by any means. Other solutions could be found like: accepting doc patches, having a rating/comment interface (but only if coding this is not at the cost of the ERP quality). 7.2. What's missing in blueprints ? Tiny feedback. May be you should also ask: what is missing in the bug tracker? -> Usually a bug tracker allows to flag bugs as bugs while re-scheduling for later version. This makes it clear the difference between a bug and Request For Enhancement (or 'blueprint'). Currently all bugs you can't fix for the very next or current version are rejected as bug and should be changed into blueprint. The result is that it' not possible anymore in the blueprint to know what is a actually a bug (even if you can't fix it now) and what is a RFE. Bugs and RFE are indeed very different and not every non quickly fixable bug should be changed into an RFE IMHO. 7.3. Someone asked our plans to improve the Report Engine ? A few things suck: - it's hard to have a changing number of columns in a table. - the removeParentNode feature is awkward - the open office plugin is still hard to use for non tech users, especially the loop thing (the scope of a loop isn't very obvious to those users) - there are serious bugs report about thing being too large in some reportlab elements, like crashing the general ledger. 8. Maintenance 8.1. Old Instance Migration In any case, my "API change" mailing list or better Google group suggestion might prevent this to happen again for future version. Having customers paying maintenance contracts will also certainly help here. 8.2. Quality Improvement Have a HUGE test suite. Bug => test case. Have a continuous integration server with public results. Have an "API change forum or mailing list" (or better Google group). So each time the API change, the community can comment on action to be taken to overcome the migration. The whole should be a straightforward process to follow for motivated people at least. 11. Marketing and communication, how to improve ? Be better at English marketing. Meet standards and get other communities from those standards jumping in. For instance be Jython compatible to encourage Java folks to jump in instead of joining Compiere or Openbravo. Be REST compliant, be WSGI compliant, move to SQLAchemy as much as possible, in a word meet the buzz wherever it is while moving to popular and good standards. Hope this helps Raphaël Valyi ------------------------ http://www.smile.fr -------------------- m2f -------------------- -- http://www.openobject.com/forum/viewtopic.php?p=33004#33004 -------------------- m2f --------------------
_______________________________________________ Tinyerp-users mailing list http://tiny.be/mailman/listinfo/tinyerp-users
