--- Jon Steinhart <jon(_at_)fourwinds(_dot_)com> wrote:
So what's the best way to go about this sort of thing? One of the
biggest
handicaps is the absence of any guidance in the form of requirements
or architecture documentation. There's no context for making
decisions on what sort of changes are worthwhile. Can we agree
on some way to work this?
The lack of documentation is a problem, for sure. There's always a
danger of breaking a useful feature that the programmer isn't aware of.
(My C hacking days are way in the past. I'm saying this
philosophically instead of with much real experience.)
The old MH book I wrote (it's online now) covers most of the obvious
features and some dark corners too. For instance, it discusses the
context stuff, how to set and use alternate contexts, and has a simple
script called "ctx" for using a different context temporarily. But my
guess is that your best resource is the people on this list and on
comp.mail.mh -- especially the folks who've used nmh/MH for many years
from the command line (not just a front-end that hides some of the
"guts").
I'd suggest that before any of us start adding and/or changing nmh
features, we post a message about the proposed change and wait a few
days for people to react. That seems to be happening now, but I
thought I'd just say it.
For the long term: I've never written architecture documentation
before. How difficult would it be to write one and add to it as time
goes on? Would a wiki or some sort of collaborative online setup let
us all rough out the outlines of good specs? I don't know.
Jerry
Discover Yahoo!
Get on-the-go sports scores, stock quotes, news and more. Check it out!
http://discover.yahoo.com/mobile.html
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers