David E Jones wrote: > On Apr 16, 2010, at 3:51 PM, Scott Gray wrote: > >> On 17/04/2010, at 8:34 AM, Adam Heath wrote: >> >>> Scott Gray wrote: >>>> Your style of communication leaves a lot to be desired. >>> And your point it? Have you realized how poorly implemented this >>> class is? That all registered services are always async. That >>> rollbacks have no chance at all of working? Such critical bugs not >>> being discovered in such low-level code make me very very worried. >> My point is that if you want people to respond to your messages then you >> should focus on the problem and possible solutions instead of using terms >> like "very very stupid" and "very poorly implemented designs". I don't know >> about anyone else but when you communicate in this manner I personally have >> interest in collaborating with you. > > There is also a significant disconnect in Adam's email that fails to > distinguish between designs and implementations. Most of the email talks > about issues with the design, the whole implementation stuff is just thrown > in there without details. I won't even get into the distinction between > requirements and designs, but actually my guess is that is where Adam's > frustration really is, his requirements are different than the ones this > design was meant to meet, but failing to recognize that issue it just looks > like a bad design and/or a bad implementation. > > This leaves the reader wondering... what is the issue here? What is it you're > trying to do that you can't? What is the proposed solution or change?
I don't ask people to fix things, unless I actually ask them. I was trying to describe my problem, to see if someone else understands the code the same way that I do. If so, I can fix it myself. If my understanding is wrong, fine. Say so. If you don't understand what I am talking about, say that too, and I'll try again. But just saying your wrong, without telling me why, won't help the situation either(not that this actually happened this time).
