Hi, first time poster, long time lurker. Apologies if I'm out of line. I work for a small systems integrator who have self-started with an in-house install, and have plans to buy OPW in the near future (we want to understand it first). So while we are not necessarily "on your radar" as significant contributors, we have started submitting patches (not me personally) and we have got first-hand implementation experience. Back to the point, if I may...
> So again, what can we announce here? That we are thinking about it? Why not? Announce an intent to look at some specific area/problem/module, and request interested parties to get in touch. Most often people can contribute their requirements, experiences with similar problems in the past or even specific use cases. > Make some > kind of planning? This is the kind of things that need a proof-of-concept. Always need a proof of concept? > And > when you have such an executable proof-of-concept, you're very close to have > the thing you will shortly announce (and people will complain because it was > not planned). Agreed, if you break cover with a proof of concept. At least if you announce your intent at the start and ask for nominations of interest, then they can't complain you didn't communicate :) Then you can still go off and do the design, prototype the way you would have, and along the way you might just have someone who's either solved this problem before, or got themselves into some horrendous mess at some point and can share a war story that warns you of an approach to avoid. If you get no significant feedback, you develop/prototype as you would have before, and everyone is happy. If you get *loads* of input, and design/prototype something that ignores it all, you'll probably get *loads* of criticism. And rightly so I'd say. (Those pesky users, as well as being a constant PITA with their constant demands, are actually a valuable source of real-world requirements.) > > Here again, the best thing to do is to write code. Only if you know you are writing code to solve the right problem, and in consideration of the greatest need. I'd argue that's what this is (or should be) about. Otherwise its coding for the art/fun/stimulation of it, not to deliver great product that meets the needs of those that use it. Just my .02. Hope I haven't offended. My coding is such you'd probably benefit more if I stuck to testing and submitting end user requirements. We have a dev that is doing some coding, and hopefully he delivers a more tangible contribution back to something that is shaping up to be a great asset to our business. Thank you. -- https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115 Your team OpenERP Community is subscribed to branch lp:~openerp-community/openerp/skitzotek_trunk_symlinks. _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
