Hi Michael,
I think there's some kind of agreement (or general direction, at least)
in this thread that
- *some* documentation of a feature is needed for various audiences
- the form of the documentation should not matter
- there needs to be a lightwight possibility to provide this
documentation
I'll take this as granted in everything I say below.
> 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,
Unnecessary? Hmm. But useful. From a given complexity onwards, I'd
*always* ask you to provide a screenshot. Not necessarily for a
(quickstarter) menu, but certainly for a complex tab dialog.
> 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.
> ...
> 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 :-)
That's a too simple conclusion, and I don't know where you take it from.
The fact that the spec you examined is obsolete, mixes a lot of
different things, as has not been kept in sync with all changes actually
done to the product doesn't justify it.
If the implementor provices a spec/documentation of the feature which is
up-to-date at the moment the CWS goes to QA, then the fact that later on
the spec quality decreases (slower or faster) doesn't mean the idea is
"totally bogus".
> 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;
I think we all in the thread got this point, which wasn't difficult
since you mentioned it often enough ;)
Perhaps we need some pool of people to approach, or something like this ...
> 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.
Sounds good to me. However, then it should also be granted that QA/UE
have the right to question/veto certain decisions, designs, etc. If we
introduce such a possibility (and I'm all in for it), then it must be
two way: The Engineer can *not* give up responsibility for the feature
as such by just firing the CWS into the "ready for QA" state.
Of course, this right needs to be used carefully by QA/UE (which
probably has not always been the case in the past).
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
