Hi Michael, michael meeks wrote:
> I understand the process is not your fault, (my frustration is not > primarily with you :-) - and that clearly some simple level of > functional spec is necessary for QA to be done etc. But please don't > defend this over-complicated, painful and substantially pointless > process. The process is not a fault at all. I don't want to start a discussion about the spec process on this list, but I also didn't want to ignore your (IMHO) unqualified rant. A specification is necessary to get the approval of all stake holders (I hope you don't deny the necessity of getting these approvals), so nothing that might be relevant to *any* of them should be omitted. You might argue that the specification does contain too much things that *currently* appear useless, but you should consider that none of us has a working crystal ball, so we don't know wich information about a particular feature might be important in one or two years. So we try to have everything in the spec that IOHO *might* be needed later. This is the same motivation that lets us write our code in a way that it deals even with strange conditions that might never happen (OK, at least we try to ;-)), something I assume you will not see as substantially pointless (though I agree that this also is painful at times). A specification shows its value over time. If you need to change something later it's always good to know why this something was done in the way it was done. As an example, it helps you to avoid damaging something unintentionally later on. A bad (or missing) specification very easily leads to a poor implementation quality with a large potential of regressions in later changes. I can show you enough "good" examples where exactly this happened because people provided only "some simple level of functional spec" as you suggested. I understand that you obviously are not interested in the stuff any longer once it is integrated, but you should respect that other people have to deal with this code a little bit longer. Of course it might be a little bit painful for you to do some extra work that *you* don't need at that time (the "core" developers feel the pain as you do!), but please try to understand that a product like OpenOffice.org is the work of a team (creating a software product is more than just code hacking) and that we need an organized way to keep the team fit for work. Nevertheless I hope to see you at the OOoCon and I'm looking forward to having some interesting and inspiring conversations with you, of course also about the spec process. :-) Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
