Hi Michael,
All looks good to me. Some comments.
* (Perhaps) Controversial
+ The primary consumer of a finished spec. is QA
So, the language used in the spec should be oriented toward QA
personnel (i.e. less advertising or "selling" tone, but more
technicality and correctness).
+ UE - get involved before before the feature is
implemented, or have some veto role
Not sure how this works out for a feature that arrives "complete",
that is, for a feature that was originally external to OO.o (hence
missed the initial discussion phase), but considered worth inclusion
at a later time.
* Proposed Changes
+ Unit Tests
+ we need a good, standard, very easy to use unit
test framework, that can trivially be extended.
+ if something is easily unit-testable, it should
have (at least some) unit tests developed in
parallel to the implementation.
Some informal guidelines may be helpful for developing unit test cases
for a new feature once such framework is in place.
* Proposed New Process principles
+ Make simple things simple
+ a fast workflow for 'uncontroversial' changes
+ clarity wrt. scope and depth of communication
Bravo. Simplicity is a virtue.
+ Split & document development practice guidelines:
+ HOWTO: iTeam formation (for those that want to)
Right. This should not be mandatory.
+ split concept of 'design requirements' / development
process, from the 'specification' [though there
may be overlap]
I agree. Splitting the specification into more specialized subsets
would be a good thing.
Also, I would like to see this list posted somewhere, and have us
revisit it in 6 months or so to measure progress.
Thank you all.
Kohei
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
