spec. process problems (take 2) ...

Michael Meeks wrote:

> 	What I'm asking for - nay demanding vociferously - is
some means of
> timing out these (non-QA) people's objections -
clearly QA is going to
> have a veto anyway as/when they do the QA on the CWS
containing the
> feature. I suggest 1 week as a reasonable period in
which (if there has
> been no response), we can switch the Spec. status to
'Standard'.

I agree that we should define these things and how to handle
the
situations where they happen. I know several examples where
this has
happened, for whatever reason. For me it boils down to the
point: how to
make sure that the necessity of finding an available QA
representative
and getting feedback from him doesn't block the integration
of a small
or simple enhancement or feature.

> 	Finally - I was *very* amused to read the
specification page:
> http://wiki.services.openoffice.org/wiki/Category
:Specification and look
> for any trace of the goal of creating great software
 There
is all
> this process, but it's goal *appears* to be
-exclusively- the production
> of good specifications, ie. specs that match what the
software is doing.
> Is this deliberate ? My personal preference would be to
put the focus
> here on having people produce great software rather
than wonderful
> specifications for bad software. Seemingly the iTeam
just have to agree
> that the spec. matches the reality [ however bad that
might be ] for it
> to be approved.

I think that this is an unfair comment. IMHO it goes without
a saying
that the final goal is to provide good software, but having
good
specifications is a prerequisite for it. There is no need to
explain
this in the specification page, every willing reader should
be able to
grasp this.

Ciao,
Mathias

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribespecs.openoffice.org
For additional commands, e-mail: dev-helpspecs.openoffice.org