Not only do I agree, I would VOTE on getting **significant**
changes/function documented (rough would be find) and APPROVED before
implementing. That would alleviate some of the tension between (at times)
conflicting goals within the development community, and set out a road-map
for other volunteers to follow.
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Glyn
Normington/UK/IB To: [EMAIL PROTECTED]
M@IBMGB cc:
Subject: When adding new function
05/29/2002 04:00
AM
Please respond
to axis-dev
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
