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
