Hi Frank,
On Mon, 2006-10-30 at 09:58 +0100, Frank Schönheit wrote:
> Right, the specification is not ... really comprehensive here. Which,
> technically, is a bug in the specification document ;)
Thankfully the code works :-) But the very concept of rampant
duplication of state all over the place is at root broken IMHO. Having
unnecessary screenshots, duplicating bi-lingual strings etc. adds
[AFAICS] nothing at all to an existing impl, but a huge amount of pain
in terms of re-synchronising things.
> I don't have an answer to this. I still think the document has its
> value. But from certain of you comments, especially the repeated example
> of "self stultifying arguments", I suppose you won't accept when I say I
> think that we're "learning by doing". In specifications as well as in
> coding ;)
Well; clearly the argument that "at least with a spec. QA can know what
the impl. should do" is shown to be almost totally bogus :-) it's
possible that spec.s are good for -something-, but we should find what
that something is, and only do that - rather than trying to replicate
War & Peace [ with pictures ], before changing a single string ;-)
> > * Why does it matter that it's broken ?
...
> I cannot but agree here. Reading [EMAIL PROTECTED], you might notice that I
> repeatedly argued that specification documents become increasingly
> useless over time, if they're not embedded in some system to ensure that
> they (means: we have a chance to keep them) up-to-date. A document
> management system, in particular, which for instance allows to search
> for the spec covering the functionality I am going to change.
Sure - the wiki is a reasonable choice here. That at least cuts a good
few steps out of the painful process [ wrt. finding where spec.s are
committed, checking stuff in / out etc. ].
> However, I fear you won't like this idea, and label it is even more
> bureaucracy.
Well, the main problem with the spec. process - beside the specs being
way too verbose ('Complete'), is the latency problem. It's all very well
soliciting input from all & sundry, but if they ~never respond life
becomes very painful indeed; particularly if you just invested a ton of
effort in trying to please people - who having done this - turn out not
to be at all interested.
An asynchronous work-flow, whereby an Engineer can implement a
feature / fix, knock up a quick wiki page describing it, commit it to a
CWS, assign it to QA, mail the dev@ui.openoffice.org list about it, and
get on with his next task would be ideal. Of course, U.E. could poke at
the wiki/issue (if they were interested & had time), otherwise it would
just proceed, QA likewise could ask questions / extend the wiki page
describing the change (if at all necessary), otherwise they could focus
on the real grist of the implementation.
So - I'm not against writing -something- down, but lets make it
absolutely minimal. Matthias Heutsch had a nice flow based on the
Solaris process that included a streamlined fast track for
'uncontroversial' changes; codifying that (and a load of timeouts for
comments) would substantially improve things.
HTH,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
