Dear Chris, > But I insist, that you wasn't asking yourself or me, what does your > change provoke and this is the problem. > Currently, I have to spend many time in looking that my functionalities > are still working and this is a problem. > >>From my point of view, you are too fast with your "solutions" and in > this I agree with Dan, that it would be > better, if you test your changes more thouroughly. > Sorry, that I get angry, if you change something without getting to the > ground of the problem.
In the past time I have fixed many bugs introduced by you. In the most cases I was able to find the perfect bug fix, but in some cases I just did not have a sufficient knowledge of the design and dependencies. I have performed the bug fixes myself on order to save both your time and your reputation. > Examples: Patterns, Undo+Paste, this preference. Yes, all those things are example of bugs originally introduced by you not me despite of the whole testing you have done. So the way I could propose is that in the future I do not fix your bugs but just report them. I think that if you fixed them yourself, the probability of an error or of a new bug could be lower. And it would be easier for you to make the tests, because of better knowledge which parts are likely to be affected. The same is valid for my parts: if you find a bug there do not hesitate to call me (I know, you don't). > This said, I havn't included my problems with the design of your code > which is often not as I would like it to > be from the architectural view. Well, we could discuss it too. I actually am not always fascinated by your code either, but if we spent some time for the privately hold discussion, we could find design solutions satisfying everyone. And if you have some design concept and do not share it, you can not expect me to follow it. > Next point: the project organization: > Dan is Director, I am Project Manager. Dan has problems as he isn't able > to guarantee that the next release is of sufficient quality. > And I do have problems to manage the project if you check in without > control. What kind of control do you mean? Do you think of sharing responsibilities for the modules? Do you think of defining some design principles explicitly? Do you think of tests? I certainly do tests, but it is not always possible to see all dependencies. If you would like to get more tests, I think that we may get more support from the beta users, because they are willing to support us. The more beta versions we create, the more test reports we get back, the less bugs remain in the program. > If you don't agree with this structure, I would like you to discuss it > with us but currently you say, that we all are equal. > This can't be the case as then the project wouldn't be manageable, at > least not by me. > So, please tell me, if you accept the current "work share" or not or > what do you propose. I accept the "work share" but not the current communication style. The last should create the illusion of all team members being equally valuable and respected. > And: software development is mainly communication, and I would like you > to do more of this to improve the code quality and > the project situation. I am open to any suggestion you could make for improving both the project code and the project communication. I am looking forward to hear from you. Best regards, Dimitry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
