When adding new function

[Glyn Normington <gl...@uk.ibm.com>]

In "RE: cvs commit: xml-axis/java/test/wsdl/faults FaultService.wsdl
FaultServiceSoapBindingImpl.java FaultServiceTestCase.java", Tom wrote:
>The text of the submit should be captured in the architecture docs that
Glyn has been working on.

I'd be very happy for Rich to incorporate his text into the architecture
guide. I don't claim sole ownership of the guide and would be happy for
commits to include changes to the guide whenever appropriate (but please
check that the diffs cover just your changes if you use something more
sophisticated than a text editor to edit html). If you are in any doubt
where to put the material, just start a completely new section and someone
can fix up the structure in due course.

In general, don't we all agree that significant commits of new function
should really include:

a) code,
b) user documentation,
c) design/architecture documentation,
d) new or updated samples,
e) new or updated testcases,
f) entries for the "changes in this release", and
g) TO-DO list updates?

Too often, I think we act as if the code is the only thing that really
matters, which means only a small percentage of the benefit of new code can
be realised.

This is a general criticism, not directed at Rich, and including myself. It
is all too easy to put off writing the other stuff.

Glyn