Hi Michael, *,

On Tue, Oct 31, 2006 at 02:27:23PM +0000, Michael Meeks wrote:
> On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote:
> > You mix up some things here. Nobody said that we need a spec for each
> > and every "tiny ergonomic fix". We need them for new features - e.g. a
> > quickstarter on Linux. :-P
> 
>       I refer you to the Sun rubric ** emphasis added.
> 
> http://wiki.services.openoffice.org/wiki/Category:Specification
> 
>       "I Want to Change Something in OpenOffice.org - Do I Have to
>        Write a Software Specification? 
>        **In general the answer is YES**. This applies to:
>        Features, Enhancements, **Defects**"

An unfair cite.
it is 
"Defects **requiring the following type of changes**: <list of criteria>"

> [...]
> > You again mix things here. This is no longer true for fixes in 2.0. And
> > nobody asks for specs for bug fixes. Please give examples where a bug
> > fix was not integrated because a spec was missing.
> 
>       It depends what you see as a bug. I see something being unusable as a
> serious bug, because I care about usability; OTOH you might call fixing
> that 'a feature' :-) Ultimately, the end-user sees it as a bug, and the
> customer must be always right - surely ?-)

Whether a spec or not is needed is not a matter of "defect or feature".
It is the question whether the UI gets changed or not. Whether something
changes for the user or not.
Due to the nature of new Features, this implies basically every new
feature needs a spec, and on the other hand specs for defects are not
the common thing, but the exception to the rule. (again depens on how
you categorize your "defect")

>[...] 
> > Of course every rule can be changed if good arguments and (IMHO even
> > more important!) good alternatives are presented.
> 
>       Sure, so the suggestion of using the wiki for specs is positive - it
> removes a biggish barrier to entry, and (perhaps) makes it more useful.
> Some other constructive suggestions might be these:
>       
>       * duplicate as little state as possible:
>               + no i18n data, no screenshots in specs

I agree to the i18n data, but not to the screenshots. At least not in
this general statement. Surely removing or adding one single checkbox to
an existing dialog doesn't need a screenshot, but that doesn't mean that
the new, multi-dialog wizard should not have those. (see other post)

>               + [ unless vital to illuminate some point ]

Ok. But I guess you have a different perception of "vital". "Obvious" is
a rather subjective term...

> [agree to the other points, especially this one:]
>       * ensure that the spec. process is filled with shortish 
>         timeouts to handle people that don't respond
> [...]

ciao
Christian
-- 
NP: Helmet - Unsung

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to