Kohei Yoshida wrote: > I also have this question: does every developer at Sun/StarDivision > successfully maintain the specs he/she wrote, and all specs posted on > the specs website currently reflect the current state of their > respective feature they describe with clear descriptions and no > ambiguities or errors?
That's the wrong question. I doubt that every developer does this "successfully". But OTOH if the implementation behaved differently than the spec defines it would mean that the implementation is wrong so the QA could write a bug to the developer. Of course he can fix it by changing the spec then. :-) This will need some consultations with their stake holders though. Without the spec the QA wouldn't be able to even find bugs in many cases (with the exception of obvious ones). We all know that no implementation is perfect and of course no spec is. But OTOH we are optimistic that both (implementors as well as spec writers) improve their abilities over time. > IMHO a feature description, and in case of ambiguities, an email or > two to the developers asking for clarification should suffice for most > cases (e.g. feature A introduce a new check box. When it's checked, > it does X, when it's not checked, it does Y The check box should have > the label that reads "Enable XYZ"). > > If a feature has some complex element, then the developer may need to > be involved to provide more assistance, but the developer's > involvement, or a spec, should not be a mandatory policy for all > cases. > > Just my opinion. Agree or disagree? Up to you. :-) I agree personally to some degree. If an existing features is changed that doesn't have a spec at all the changes should be described in simple terms. But in the issue, not by email. If a feature is changed that has a spec the spec should be changed (old version should be kept as a reference for the old OOo version). If the spec really turns out to be completely out of sync with the feature it should be treated as it wasn't there (IMHO). That means the developer shouldn't be urged to correct it. Ciao, 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]
