Chris Bowditch wrote:

> ideas because they didn't yield 100% compliance. Regardless, 
> my main point in this thread was simply that compromise is 
> the key to getting to a release. Which is one of your points 
> above, right?

Not really. I agree with the importance of getting along where possible, but
compromise is a relatively unimportant piece of that. Far more important is
building, by persuasion and sound reason, *unity* within the team about the
direction of the project. The willingness to compromise, to yield on
relatively unimportant issues for the sake of the bigger issues, implies a
level of unity about the bigger issues. Compromising on pragmatic issues is
important and useful, compromising on fundamental issues is suicidal.

Now, I think FOP has a fair amount of unity right now, and I am glad for it.

WRT 100% compliance, you do not have to achieve 100% to make something
useful. (However, I will argue that you should not call something 1.0 until
that is achieved). But the important issue is whether your basic design will
allow you to eventually get to 100%. If you lock yourself into a design that
will *never* get you to 100%, then you mandate another rewrite. So yes, I
think it is a duty for any FOP developer to speak up when he sees that kind
of situation arise. And yes, I think it would be unwise to compromise on
such a matter. So, no, I did not mean to imply that "compromise is the key
to getting to a release."

I am sorry for that this discussion became inflammatory. I thought my
original comments were innocent enough, but it is clear that I should not
have made them.

Victor Mote

Reply via email to