No subject

be close to mechanical. ("Step 1. In the Foo panel, select the target
library from the Bar widget. The Frambazzle dialog opens.... Step 2...")

A colleague of mine used to say "If the UI's a dog, the help will bark."
If the help is barking early on in the documentation process, that might
be early enough to suggest that some change would be good. If the
documentation is held off until the end, though, then that's a missed
opportunity for feedback.

END SIDETRACK (this one, anyway)

> these changes are developer driven and sometimes it's the client - but 
> providing documentation at any stage prior to the final tested version 
> would be misleading at best.  That said, Equinox is aspiring to provide 
> better notes to the community of features that are in development.

Good to hear!

> Now, getting the documentation out at the time of release?  That should 
> be an achievable goal for Equinox; however, I can't speak for the 
> community developers - and all the developers should be held to the same 
> standard.  Since there isn't a "client" who is commissioning the work, 
> perhaps the community developers could use DIG as they go along their 
> development path to provide testing and documentation.

I hope that Equinox doesn't see itself as being separate from DIG or
community development. Crazy idea: if part of the release standard was
"no new feature goes into the official release without adequate
documentation" and DIG was the arbiter of what "adequate" meant, then it
would be a level playing field for all. If a site had the technical
chops to create a cool feature COOLF, but could only provide basic notes
about how COOLF worked, then the community could rally around writing up
docs for COOLF; or another site could hire a professional tech writer to
provide docs that DIG would deem adequate if they wanted to get it into
the official release.

Keeping features out of an official release due to a lack of
documentation may be a crazy idea, yes. But a boy can dream. I think
these (who decides what's in an official release? Hey, should the docs
be part of the release tarball? Or at least offered for download as a
separate tarball?) are very healthy discussions to have. Development is
development, whether it's paid for via a contract, or paid for via a
salaried position, or paid for via somebody's volunteer time when their
kids are asleep and they could be doing 1000 other things. Documentation
is exactly the same, and is arguably as valuable as the code underlying
the features it explains.